BreakingPoint: Just took some great video of BreakingPoint CTO Dennis Cox, really cool stuff that will put up on the blog for everyone.

BreakingPoint: Just took some great video of BreakingPoint CTO Dennis Cox, really cool stuff that will put up on the blog for everyone.

BreakingPoint: Just posted "Four Critical Priorities for USCYBERCOM". Agree? Disagree? http://bit.ly/Nx6In

BreakingPoint: Just posted "Four Critical Priorities for USCYBERCOM". Agree? Disagree? http://bit.ly/Nx6In

BreakingPoint: RT @DrInfoSec: RSA Conference 2010 Announces Call for Speakers http://bit.ly/feya9

BreakingPoint: RT @DrInfoSec: RSA Conference 2010 Announces Call for Speakers http://bit.ly/feya9

BreakingPoint: Are you quacking your way to a new Flip Cam from Cisco CEO John Chambers? http://is.gd/1rf15

BreakingPoint: Are you quacking your way to a new Flip Cam from Cisco CEO John Chambers? http://is.gd/1rf15

BreakingPoint: Check out the post from @devcentral "What's In a Cloud Anyway?" http://tinyurl.com/nakv94 Looking at cloud without the hype.

BreakingPoint: Check out the post from @devcentral "What's In a Cloud Anyway?" http://tinyurl.com/nakv94 Looking at cloud without the hype.

Four Critical Priorities for USCYBERCOM

"Cyberspace and its associated technologies offer unprecedented opportunities to the United States and are vital to our Nation's security and, by extension, to all aspects of military operations. Yet our increasing dependency on cyberspace, alongside a growing array of cyber threats and vulnerabilities, adds a new element of risk to our national security."

--Secretary of Defense, Robert Gates

During most of the past year, military and cybersecurity experts have been calling for the creation of a cyber command within the Department of Defense (DoD). On June 23rd Secretary Robert Gates' memorandum established U.S. Cyber Command (USCYBERCOM) to address the current risks and "secure freedom of action in cyberspace". The announcement was met with much fanfare from the defense community, but simply announcing USCYBERCOM is the easy part. Actually building the command center is the real challenge.

The next step is to deliver a USCYBERCOM implementation plan for approval by September 1, 2009 and there is much speculation about what will be included in the plan. What are the top priorities for securing our nation's private and public cyber infrastructure? Who or what are the greatest threats? Which approach offers the greatest protection? How will the various departments and countries work together? 

During a week in which we witnessed one of the more high profile cyber attacks against government networks, I set out to get answers to those questions. It became clear that there are at least four top priorities for USCYBERCOM to consider before the September 1st deadline:

1. Establish buy-in throughout government agencies to ensure they are working together.
2. Properly define the USCYBERCOM mission including establishing a set of manageable priorities.
3. Identify and prioritize network vulnerabilities while establishing a set of security standards.
4. Create a cyber SWAT team to act as first responders in the event of an attack and to deploy measures to thwart escalating attacks.
   

1) Secure Buy-In for USCYBERCOM

Creating buy-in throughout government agencies has for decades been the single biggest threat to our nation's security. This is why, before USCYBERCOM can establish themselves and their initiatives, it must establish intra-government support to ensure various government agencies are working together, not against one another. This support is a critical factor in getting USCYBERCOM up and running, and will be necessary for the success of the cyber SWAT team (#4 on the list).

Ken Pappas, the Vice President of Marketing and Security Strategist for Top Layer Security, has spoken with many government groups about this challenge and believes that the most difficult objective for USCYBERCOM is not implementing security measures, but rather gaining support and trust of all agencies that will be affected by this. This is why Pappas proposes USCYBERCOM's first objective should be to win the support of all agencies and have them become stakeholders in the plan, as well as the execution, monitoring and success of the new command.

Securing buy-in for USCYBERCOM is certainly already underway through meetings with DHS, NSA, intelligence agencies, the military branches and more. Together, these groups will establish a "state of the cyber union", helping to determine what is already happening, where different parts fit and what elements are the most important. Working together now towards buy-in leads to a clear picture of what is needed and helps define the mission for USCYBERCOM.

2) Establish USCYBERCOM's Mission and Priorities

Avi Deitcher, the founder of Atomic Inc., recognizes the importance of establishing a clear vision, because without it USCYBERCOM will fail, "In the words of Frederick the Great, he who defends everything, defends nothing." It is imperative that USCYBERCOM properly defines their mission and within that mission outline the priorities of the command.

The challenge, of course, is that a main priority to DHS might not be priority number one for DoD. Certainly some of this will be resolved through the buy-in phase, but there will be issues no matter how coordinated different agencies become. A critical part of establishing the mission will be the people who are chosen to lead USCYBERCOM in the trenches. In fact Pappas argues that people are the key to the success of the mission, "First selecting the right people to undertake this task should come before anything else. Then comes the vision, then strategy on how to execute, then funding."

People are going to be a key element for USCYBERCOM but without a clear mission these people will be set up to fail and the set goals will not be achieved. Pappas continued, "What is the goal? I don't think anyone has figured this out yet. Hence a vision needs to be made and bought in. What are we protecting and from who?". With the vision, mission, and people in place it will be time to identify exactly what needs protecting.

3) Identify Network Vulnerabilities and Set Security Standards

During the buy-in phase there will be knowledge gathered to identify network vulnerabilities, but that will merely scratch the surface. Creating a clear picture of all network vulnerabilities will help USCYBERCOM set priorities. Fortunately, this is an area where the government can use technology. Resiliency testing provides a first step in identifying the weak spots within a network by hitting devices with realistic application traffic, up-to-date security attacks and line-rate throughput. Testing in this manner reveals the flaws of network equipment, even taking into consideration DDoS attacks, botnets, application fuzzing and more.

Once you perform this level of testing, priorities will become readily apparent. Additionally, resiliency testing of new equipment to be deployed sets a "cyber security standard".  There are so many different networks and disparate security initiatives to protect these networks that the "cracks" may be quite large, any testing standard introduced helps create a safety net under those cracks in the system.

Mixing in a standard, within an overlapping set of cyber security initiatives, is smart strategy, for net-centric defense and beyond. Mr. Pappas notes, "If this [seperate agency cyber security initiatives] is how it is starting out, then each agency is going to have its own mini cyber command and disparate systems once more. This is common within US Government agencies. One of the good things that comes out of this however is that the hackers cannot use the same tactics to gain access to ALL agencies. So following a 'standard' for all agencies might not be a bad strategy."

Having each government network uphold to a baseline set of standards will be important in order to act across these networks during an attack. If each have met a set of security standards USCYBERCOM will have an easier time responding to and preventing attacks. Knowing that each piece of equipment has been resiliency tested, under approved standards, will immediately tell USCYBERCOM, or any cyber security initiative, where the potential holes live, how to route services so they come back up faster and allow them to respond quickly enough to avoid permanent damage to any net-centric infrastructure. As the government takes the lead in setting standards to improve the resiliency of network equipment, private enterprise will benefit by having access to far more resilient, high performance equipment. 

4) Create a Cyber SWAT Team

Once buy-in, vision, priorities and standards have been established, it is now important to act quickly in establishing a team of first responders in the event of a massive cyber attack. Mr. Deitcher was clear what he would advise, a crisis center, "Put in place a team that coordinates a response to all attacks and breaches. It is acceptable, and may even be preferable, that each department and/or area has its own team with its own priorities. However, when an attack does come in, it is crucial that a central "SWAT" team be apprised of it."

This becomes increasingly important, as Deitcher points out, when an attack occurs on a government agency that might not have the necessary cyber security expertise but needs to stop the attack and prevent it from hitting other agencies. USCYBERCOM, if built correctly, can certainly be a center point for this cyber SWAT team, helping to monitor for attacks and taking actions, across departments, when an attack occurs. Additionally if resiliency testing standards have been applied USCYBERCOM can more quickly respond and end any attack.

Conclusion

USCYBERCOM has an enormous challenge ahead of them and here we have only provided four of the most important recommendations. However, at the end of the day, this still all comes back to people, as most things do when you are talking about network security. This fact struck home while talking with Mr. Deitcher, who succinctly stated that the most pertinent cyber threat to the United States today is incompetence.

USCYBERCOM can help eliminate and shore up this threat of incompetence by establishing buy-in throughout the government, establishing a clear vision, identifying vulnerabilities through resiliency testing and creating a cyber SWAT team. It will be interesting to see what is presented to Secretary Gates in just eight weeks.

Don't Put All Your Eggs in One Carton

First, some quick definitions:

An Exploit is a working version of code that takes advantage of a vulnerability in a product. The exploit could crash the product, or it could make it open for remote access (for someone to get into your computer).

A Vulnerability is a flaw in a product. A well known flaw in programs is a buffer overflow. A buffer overflow is when a program tries to give more data then the program it's talking with can handle. In layman's terms, let's say you try to put 13 eggs in an egg carton, one's going to fall and crack. You overflowed the carton. The carton can only fit a dozen eggs and when you put too many eggs in bad things happen. Let's go with the egg analogy for a bit.

Now imagine you work at the market and your job is to check every carton of eggs. So you decide if you see 13 eggs then you will throw away the carton. This works okay - but you are checking for the exploit not the vulnerability. If I put in 14 eggs, you won't detect a problem, since you are only looking for 13 eggs. A true vulnerability detection would be "if there are more then 12 eggs".

Most security vendors say they are vulnerability-based not exploit-based, however it is a rare vendor that can do mostly vulnerability filters. Luckily there is an easy way for you to prove this fact. Look for filters that are enumerated (exploit.1, exploit.2, exploit.3, or exploit.A, exploit.B, exploit.C) or go social media on them and search their blogs.

After looking around for a bit you'll quickly find that vulnerability filters are a rare find. The reason vulnerability filters are rare is because they generally require intimate knowledge of how the program works internally (source code). On the other hand, exploit signatures are trivial to create. If I know what the packet looks like, then I just match on that packet. An exploit is generally a fixed packet(s), which makes signatures trivial to write. Since they are specific, they do not provide as effective security as a vulnerability filter.

Certain companies literally do not know how to write vulnerability filters. The two main reasons are either the product they develop can't do the complex matching needed for a vulnerability filter or they don't have the skillset to create them. For example, in late October W32.downadup was released (popular name Conficker), everybody released signatures for it fairly quickly. In December another variant of the exploit came out. It bypassed pretty much every antivirus and IPS system. Those vendors then released new filters, and by mid-March two more variants were found, which bypassed all the same vendors again. Variant E (number 5 if you are counting) came out in April followed by the subsequent release of filters from most of the vendors. What does this tell us? First and foremost, people are not writing vulnerability filters. And secondly, you are not getting good protection out of the exploit signatures. To write an exploit filter (signature) you need to have a copy of the exploit in the wild. That means the exploit is already out and you are doing damage control not prevention.

Let me pick on some vendors for a minute. I picked these three because to be honest, they have the BEST websites for finding out this information. If you are a customer of the below, be happy, your vendor isn't trying to hide anything from you and they each have great websites to boot.

McAfee Conficker.A Nov 24, 2008 Conficker.B Jan 06, 2009 Conficker.C Mar 10, 2009 Conficker.D Mar 11, 2009	Fortinet Conficker.A Dec 05, 2008 Conficker.B Jan 02, 2009 Conficker.C Mar 10, 2009 Conficker.E Apr 08, 2009	CA Conficker.A Nov 24, 2008 Conficker.B Jan 05, 2009 Conficker.C Mar 11, 2009

For those not listed, don't think it's because you made a vulnerability filter, it's just I didn't need more then three examples. F-Secure, Cisco, 3Com and I'm sure others all have similar information online with multiple releases of the filters to block Conficker.

Why is this all important?

You want a vulnerability filter. Every vendor will tell you that the perfect solution is a filter that blocks the vulnerability. With a vulnerability filter, you remove the need to update every time a new variant comes out. You block the bad stuff every time, no matter what.

BreakingPoint has the tools to test vendor filters to see if they provide adequate protection against threats. We do this by using a pseudo random number generator (PRNG) which you initialize with a value. This value is generally referred to as a seed. The PRNG uses this seed to generate random data in the parts of the exploit that doesn't matter - for example the first 12 eggs. Instead of sending 13 eggs over and over again, it will generate 14, 16, 204, etc., eggs.

The PRNG however is not actually random - it's pseudo random. If you look up pseudo in the dictionary it will say "not genuine; sham". That's right, it's not random - and that's good. We want you to be able to pick a number and generate the attacks (or application data) the same way every time. Meaning, if I choose seed "4" it will generate [20, 21, 2045, 657,...]. If I choose "5", it will generate [516, 352, 6246, 2657, ...]. This way I'm generating all variants, but in the same way. If you want something repeatable - always use the same seed.

It's possible to write signatures that are exploit-based but are smart enough to block future variants, and BreakingPoint testing tools allow you to prove it during product bakeoffs. But more importantly you can find out if their engine can handle any vulnerability filters.

Taking A Look at OWAMP

The One-Way Active Measurement Protocol or OWAMP was developed by the IP Performance Metrics Working Group (IPPM) as a part of the Internet Engineering Task Force (IETF). The IPPM Working Group, which I am involved with, develops metrics and processes for measuring IP performance in networks; OWAMP is one of those protocols. Specified in RFC 4656, OWAMP creates a process by which one-way measurements such as latency and packet loss may be made.

In reality, OWAMP is the umbrella specification for two underlying protocols: OWAMP-Control (OWAMP-C) and OWAMP-Test (OWAMP-T). OWAMP-C runs over TCP port 861 and is responsible for the negotiation of the various parameters necessary to successfully complete the measurements.  Additionally, this protocol handles the communication of the measurement results back to the initiating host. The OWAMP-T protocol actually sends the test packets, which are used to calculate the appropriate metrics. This protocol runs over a UDP port to be negotiated within the OWAMP-C session. The IP address of the sender and receiver are negotiated as well, allowing physical separation of the OWAMP-C and OWAMP-T endpoints.

OWAMP is a natively supported protocol within BreakingPoint testing tools and we have put together an OWAMP Application Protocol Brief that further illustrates the finer points of this measurement protocol and the benefits you gain by emulating the protocol during testing.

*This is the second in a series of Application Protocol Briefs, the first brief featured was on Citrix.

Resiliency Testing Critical to U.S. Cyber Infrastructure

It appears that talk about the United State’s plans for beefing up our country’s cyber infrastructure is finally turning into action with new details emerging about government plans to create U.S. Cyber Command. Just this week, Defense Secretary Gates approved the creation of U.S. Cyber Command (or "Cybercom). Jaikumar Vijayan wrote the story for Computerworld and explained:

The proposal to create the new command has been expected for some time and is part of an effort to address growing threats to Defense Department and Pentagon networks from foreign and domestic threats.

Those of you in security research have seen much of this coming. The threats have always been out there, but they are now becoming more sophisticated and more frequent. Security attackers are also becoming more creative. Witness the DDoS attack orchestrated by Iranian protesters via social networks this month.

In the testing world we understand that no matter the initiative or the person heading it up, there are going to be challenges for the government agencies, contractors and research organizations tasked with implementing and ensuring the resiliency of mission-critical networks, as well as the devices and the services they deliver.

"Resiliency" is a word that perfectly describes what people are looking to test when it comes to U.S. cyber infrastructure. Resiliency encapsulates both security and performance of the network and the devices that serve as it's infrastructure. If you want to test the resiliency of a device, you have to do it with real-world network scenarios and network simulations. All of this sounds familar to anyone who has been reading this blog since BreakingPoint excels at testing with realistic app traffic, security strikes, line-rate throughput and more.

This morning we put out news around our capabilities in resiliency testing, "BreakingPoint Provides the Only Realistic Network Simulation for Testing Vulnerability and Resiliency of U.S. Cyber Infrastructure". I wanted to share with you a quote from the news release from Des Wilson, BreakingPoint's CEO, where he defines resiliency testing and its importance:

“Resiliency testing is clearly critical to identifying and eliminating threats to the security and performance of our nation’s cyber infrastructure. And the definition of resiliency testing remains simple; test the network and network devices using blended application traffic mixed with live security strikes at line-rate speeds originating from the same address space. However, until today, the government agencies and organizations tasked to optimize and defend the cyber infrastructure did not have these capabilities. BreakingPoint Elite is the only testing tool architected to simulate the conditions of an actual network, providing the resiliency testing capabilities that help make it the only effective defense against net-centric threats and performance issues.”

How do you define resiliency testing?

Constantly Hacking Ruby Constants

Here at BreakingPoint, we write all of our application simulation code in Ruby. Lately, I've been working on adding a slew of new behaviors to our IMAPv4 implementation so users can fine-tune their IMAP Application Simulator and Client Simulator flows. At first, this seemed like it would mean a whole lot of typing to wire up twelve new actions.

Instead of copying and pasting all over the place (and dreading the possibility of fixing the same bug in fifteen zillion places), I needed to come up with a code reuse technique that takes advantage of the existing codebase written using standardized naming conventions. Since I'm swimming in these standard names, I figured there must be a way to use Ruby's dynamic typing and extensible classes to make this easier on myself, both now and in the future.

The first trick is to programmatically figure out which application profile class to use when I'm in a particular protocol. For example, if we're in a function in the "Imap" object, I need to get protocol configuration from the "ImapProfile" singleton object. This is pretty easy with Ruby's introspection and the nifty Kernel.const_get() function.

So, let's say we have a (simplified) ImapProfile class:

class ImapProfile def self.config
        {:username => "todb",
         :password => "Shadowfax" # Unguessable! 
        }
 end
end

In the Imap subclass of Application Manager, I'll want to get a hold of those configuration parameters. I can do so with something like this:

module AppManager class Imap

  # Get my class name, strip off the superclass
  def my_protocol
  self.class.name.to_s.split("::").last
  end

  # get_profile_params() takes the string from 
    my_profile_object(),
  # gets the associated constant, and invokes 
    the config() method. def get_profile_params
  Kernel.const_get(my_protocol + "Profile").send :config
   end

   end
end

Now we can call the profile object's "config" method by deriving the class name from our own class's name:

irb(main):001:0> @app = AppManager::Imap.new=> #
irb(main):002:0> @app.get_profile_params
=> {:username="todb", :password=>"Shadowfax"}

That's pretty neat and all, but the real trick is to figure out how to do the same thing with a method name, since (as you'll see) they bear a resembelence to individual action classes. After a little bit of research, it turns out we can perform something similar with the Kernel.caller() function, and again use some string manipulation to get what we want:

def caller_action_to_constant        caller[1] =~ /`([^']+?)'/
        $1 =~ /^do_(client|server)_(.*)/
        $2.split("_").map {|s| s.capitalize}.join
end

This function takes the second element of the execution stack, extracts the calling method's name (the first regex), extracts the part we care about (the second regex), then splits on the underscores in order to CamelCase the result. In the end, the string:

"do_client_send_user_name"
becomes 

SendUserName

Why not the first element of the call stack array? Well, I'm wrapping this up in an intermediary function, called the action_executor, which takes this string and performs another const_get to actually use it for something:

def action_executor(args={}) Kernel.const_get
(my_protocol + caller_action_to_constant + "Cmd").send :data
end

So, from now on, the do_ actions can call the action_executor in order to track down the right classes to get the data from:

def do_client_send_user_name(args={})        action_executor(args)
end

Pretty neat, if you ask me. A complete code listing should be available here, at Pastie.

In the end, this strikes me as an implementation of the OO Delegation design pattern. However, it includes some extra smarts about where the delegatee is, all based on a common naming convention for classes and methods. While the example code is sparse, in reality, the application actions I'm replacing in IMAP were each around 15 lines, and this technique compresses them down to one. I also get the added bonus of centralizing a common function to one spot, to ease future tweaks to the way application protocols work, or, the laughably remote possibility that there's ever a bug discovered there.