We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson

We've probably all heard that you can't secure what you can't see and that statement is even more profound when it comes to virtual environments.  This is because it is extremely challenging to see what is going on at a micro vs. macro level within a virtual environments network.  The virtualization vendors such as VMWare and Citrix have provided embedded tools into their management consoles that show a macro level of visibility but its not enough to identify security events in the environment.  Take a look at the attached picture.  It simply shows VMWare's ability to monitor virtual network performance statistics from a bits per second perspective.

<-Click To Enlarge

With only this level of detail how can one determine which network applications are causing spikes.  Is it FTP traffic that is occuring at a high volume at an unuseal time of day?  If that were occuring, could that be indicative of either a breach or some sort of problem? What if FTP isn't even an authorized service in the virtual environment but there is a high volume of it?  Did someone install a rouge FTP service so they could steal information from the server at will?

These types of questions can't really be answered without a micro level of detail into the packets flowing in, out and within the virtual environment.  Now, what I am highlighting is not security in the traditional sense of prevention but using visibility as a means to first identify, then pin point the source of an issue so that it can properly be mitigated.  Having constant visibility can also ensure that other security products in the environment are performing as expected.  What if a Montego HyperSwitch with firewalling enabled is configured with many policies but someone forgot to create an FTP block policy.  One could think they are protected from rouge FTP services transmiting data out of the network, but without constant visibility monitoring, can you be certain?

Some vendors, namely Reflex Security will get you to believe that their IPS / IDS solution that is inline and running in the virtual environment is the right and only approach.  Or they will tell you to hang a virtual IDS off a span port in the virtual environment and you will at least have visibility into the attacks that are taking place.  Well, sure... You now have attack visibility but at the performance cost of your virtual environment.  Signature matching technologies are great, I'm a huge believer; however they don't scale very well in shared computing environments such as virtual ones.  IDS systems also don't typically track protocol and network service (FTP, HTTP, etc.) utilizations; which is another important part of visibility.

So, what do we do to gain visibility without the performance headache?  Well, for starters its probably best to put your IDS/IPS solutions in the physical environment where performance will be less of a concern.  In fact, you can span a virtual switch's traffic out to a physical NIC as easy as you can to a virtual one.  So why do it virtual and have to pay a 60% CPU utilization tax?  Another solution is to IDS inspect only the things you care about.  Why IDS inspect SSL traffic if you know your solution can't unencrypt SSL.  Its just a waste of compute cycles isnt it?  Policy based switching helps you with directing only the things you care about to an IDS (attack visualization product).  Montego's HyperSwitch also can help you with the traffic redirection of only the things you care about.

Another method of visibility which I tend to be a fan of is one of packet analysis (aka NetFlow).  NetFlow was invented by Cisco some time ago and has gained popularity in the physical world and definately has a use in the virtual world.  NetFlow is lightweight.  Let me say that again, its light weight!  It only sends a summation of packet detail to an analytical engine which can do some number crunching, packet comparison, etc. etc. to make some sense out of whats going on.  Lancope, an Atlanta based visibility company that provides Network Visibility, Security Visibility and User Visibility has this tool on their website that is a Netflow Bandwidth calculator.  You'll see from playing with this ( http://www.lancope.com/netflowcalculator.aspx ) calculator that it doesn't consume a lot of network bandwidth to transmit these network accounting records.  It also doesn't cause a lot of CPU overhead to send these records to an analytical engine sitting somewhere in the network.

Lancope's analytical engines have the ability to do the following for you within your virtual environment:

...and probably a slew of other things I'm not aware of.  A screen shot of their product is bellow:

<- Click to enlarge

You'll notice from the screenshot that you are able to visualize who is talking to who, how much traffic they have sent and received and something called a concern index (not seen on this screenshot).

Now, a concern index is a number that increases as Lancopes analytical engines monitor suspicious activity on a session.  A high counter can be indicative of a security problem.  Its another way of identifying (visualizing) compromised hosts (virtual machines) without having to do signature matching like a heavy weight IPS engine.  Example:  Lets say you have a VM that has a BOT on it and is "owned".  The Lancope product is monitoring this long life session.  Let's say that session is established for several hours or maybe even days or months.  Lets also say that the conversation appears to be mostly unidirectional from a public ip address not belonging to your enterprise.  Lancope would increase a the concern index on this since this server hasn't typically had this type of behavior.  Once the concern index reached a certain level it could then fire off an email, send you a text message or something saying:  Warning, Warning, Danger, Danger Will Robinson!!! You're virtual server may be infected with a BOT, please investigate immediately!!!

This example is VISIBILITY which helps you with SECURITY.  There are a number of other things you can do with NetFlow and Lancope products that have less to do with security and more to do with operational efficiencies.  Things like, helping you answer questions of:  How do I know what network applications are taking up the most bandwidth?  When should I move those applications over to a server with more horsepower?  When did these VM's vmotion over here and was there a traffic condition / CPU condition that caused that to occur?  I could go on and on but thats a topic for another blog entry.

So, my suggestion is to take a look at what NetFlow has to offer.  Montego Networks supports NetFlow transmission and Lancope supports NetFlow analytics and with both you can regain what was lost visibility.

I hope this was helpful to you all!

-John Peterson

Upping The IPS Ante

Motorola announced this week its intentions to acquires Wireless IDS/IPS vendor AirDefense. The acquisition may provide a bit of deja vu to readers who recall the acquisition of Network Chemistry's wireless IDS/IPS assets by Aruba Networks in 2007.

Meru Networks, eschewing acquisition for product introduction made its own announcement on Monday, announcing the company's RF Barrier, an active RF management solution that aims to solve the problem of what the vendor is calling "leaky RF." The Meru solution actively blocks 802.11 RF from escaping the physical confines of a WLAN deployment to thwart external "parking lot" attacks by closing Wi-Fi based attack avenues.

In fact, 2007 - 2008 has been a time focused on shoring up the security of the WLAN as the networks become more critical to over 50% of enterprises Forrester sees investing in the networks today. As the networks are more pervasive, moving toward covering the entire physical environment, and more employees are relying on Wi-Fi to access corporate data and applications, it's high-time to secure the WLAN.

In the case of Motorola, the Wi-Fi network is especially critical. As the vendor embarks on selling its message of the all-wireless enterprise, where WLANs will interconnect not only users to the network, but networke edge devices -- such as WLAN access points -- to the network along with storage, printers and other peripheral devices, the WLAN is citical and, therefore, a major focus for security.

In markets such as retail, standards like the Payment Card Industry's Data Security Standard dictate wireless security, but compliance and regulation aside, it is becoming easier to secure the WLAN, regardless of the industry you are in. Vendors are rapily working to close security gaps with product enhancements and new product introductions. Look for a broader suite of solutions to address security coming from your primary network vendor; while this won't negate the need to  integrate these add-on network elements, the single source should ease integration to some degree.

How secure do you feel your organization's WLAN is today? What are your concerns either about securing the network or its current lack of security?

Blogger: Pete Lindstrom

On July 8th, Dan Kaminsky of IOActive announced a major DNS “vulnerability” in conjunction with a number of major DNS vendors. The announcement was off the charts in fanfare and attention, but what was the real impact on risk?

First, it is worth noting that this “bug” is more properly classified as a new attack technique invented by Dan. It combines two vulnerabilities that have been well-known for some time – the ability to guess non-random transaction IDs and the use of Additional RRs to insert new entries into the DNS cache. A fix against either of these vulnerabilities also negates the attack itself.

The fundamental question that determines the risk impact revolves around whether it is reasonable to expect fewer or more incidents that use this technique when comparing the period prior to disclosure -- or, more properly, before the date of Dan’s invention of the technique (this also assumes prior art) – with the period after invention/disclosure and into the future. If the disclosure reduces the number of those incidents, then risk is reduced; if the disclosure increases the number of those incidents, then risk is increased.

With that litmus test as our guideline, it is useful to break down the functional elements of risk and look at the impact on threats, vulnerabilities, and consequences (we will cover consequences, then vulnerabilities, and finally threat).

Consequences
Though the consequences are the same before and after disclosure, it is worth discussing the impact here, given that the implication was that the “entire web” could be taken down. The nature of the attack requires the following:

1. An attacker must convince/trick a user into making a DNS request for a domain that doesn’t already exist in their DNS server’s cache. The expectation here is that s/he can be easily tricked into doing this.
2. Then, the attacker must simultaneously attack the DNS server by guessing the transaction ID. According to Kaminsky, the request/attack phase can be done reliably in about 10 seconds.
3. The attack is DNS server-specific. Only users on the same DNS server are affected.
4. Propagation: once the cache is poisoned, anyone requesting that domain will be routed to a malicious server.

Without combining this attack with other attack techniques, there can be three results:

1. Spoofing of a single website for multiple, perhaps many, users using the same DNS server. Presumably, this would be followed by more traditional phishing and malware attacks.
2. Denial-of-service by rerouting traffic from a legitimate site thereby taking potential customers or “eyeballs” away.
3. Denial-of-service be rerouting traffic from a legitimate high volume site to a legitimate low-volume site thereby overloading the servers on the low-volume site.

Because of the point-to-point (user-to-website) nature of the attack, to do something that constitutes “taking over the entire web” is infeasible by a longshot.

The bottom line analysis for the effect on risk due to a change in consequences from pre-invention to post-invention: no change, and therefore no impact.

Vulnerabilities
These vulnerabilities have existed for years, and there have been workarounds for years. Along with this announcement, new patches were introduced in all major DNS server solutions. It is reasonable to assume that many DNS server implementations have been patched, though public accounts have suggested that number is in the 66%-75% range.

Bottom line analysis: the vulnerability level has been reduced, probably significantly, and the affect is positive for risk reduction. If 100% of DNS servers were patched, then overall risk would be reduced for this attack (assuming that there were actual attacks using this technique in the past.)

Threats
The real question regarding risk impact comes in the arena of the less-controllable manipulation of threat. The general threat equation revolves around an attacker’s willingness to attack, based on his/her own cost/benefit analysis that compares the cost to attack to the expected benefits, tempered by the potential for being caught and penalized.

Cost to attack – prior to disclosing the invention, there were likely few, if any attackers with “prior art” that mirrored this technique. It is anybody’s guess how many potential attackers might have figured it out eventually, but they would have had to come from the pool of folks with enough expertise to do so – I am going to guess 500,000 people.

After the disclosure, the hints provided in the press release, the podcast, the sorted stories, and the blog entries made it much easier to figure out. Let’s guess that 5 million people could execute the attack. With automated tools, that number goes up to 50 million.

These numbers are estimates that illustrate the nature of the exercise. You are welcome to fill in your own estimates and come to your own conclusions.

Bottom line analysis: a significant increase in threat and corresponding risk.

Net Effect
The risk manager's challenge is to weigh the decrease in vulnerable systems compared with the corresponding increase in threat, within the context of number of incidents and anticipated future incidents. Given the sheer size differential, it is difficult to conceive of a situation where risk is not increased.

Sometimes it "feels" like someone is taking action for the greater good, when that action actually creates a negative impact for all. For example, it is common for people to believe that raising prices of scarce resources during  times of trouble (e.g. gasoline in the hurricane Katrina aftermath) is unconscionable even though a majority of economists recognize that raising prices actually provides for the greater public good. Vulnerability discovery and disclosure, and attack inventions, might feel like the right thing to do, but the net result is almost always a negative impact.

Who doesn't remember the cone of silence from the original Get Smart TV series.  Whenever Max and the Chief had something important to discuss they would lower the cone of silence so that no one else could hear them or eavesdrop. So it is only fitting with the recent release of the Get Smart movie, Meru Networks has released a wireless cone of silence.

Meru is one of few stand alone wireless companies still hanging on out there.  So they need to be innovative to survive.  Their latest product, RF Barrier puts antennas around a physical plant to dampen and make it impossible to to listen in on wireless data exchanges.  They claim this is a first of its kind.  Thinking about it though, I don't see a big barrier to other companies having similar technology. I don't think you have to be a genius to broadcast traffic that puts out "noise" to hide legit traffic. I think the real special sauce is that this works in conjunction with Meru's other security products like wireless firewalls and secure access points.

With Motorola's recent purchase of AirDefense is having wireless IPS soon going to be table stakes in the wireless provider game?  I think it is and while Meru's RF barrier is a nice story, they are going to need to have some sort of IDS/IPS in their product line to keep up.

Who doesn't remember the cone of silence from the original Get Smart TV series.  Whenever Max and the Chief had something important to discuss they would lower the cone of silence so that no one else could hear them or eavesdrop. So it is only fitting with the recent release of the Get Smart movie, Meru Networks has released a wireless cone of silence.

Meru is one of few stand alone wireless companies still hanging on out there.  So they need to be innovative to survive.  Their latest product, RF Barrier puts antennas around a physical plant to dampen and make it impossible to to listen in on wireless data exchanges.  They claim this is a first of its kind.  Thinking about it though, I don't see a big barrier to other companies having similar technology. I don't think you have to be a genius to broadcast traffic that puts out "noise" to hide legit traffic. I think the real special sauce is that this works in conjunction with Meru's other security products like wireless firewalls and secure access points.

With Motorola's recent purchase of AirDefense is having wireless IPS soon going to be table stakes in the wireless provider game?  I think it is and while Meru's RF barrier is a nice story, they are going to need to have some sort of IDS/IPS in their product line to keep up.

Because of non-disclosure and other confidentiality contracts with various partners, vendors and manufacturers, we’ve had sealed lips for almost exactly 12 months. Now that it’s been made public by the media, I can share a little information with you and explain why I think you should be excited.

What cat is out of the bag now? HP ProCurve’s network access control solution leverages endpoint management technology from StillSecure’s Secure Access solution. Information Week spilled the beans, so to speak, in Mike Fratto’s recent 2008 NAC Survey Analytic Report. (See page 32)

Now, at this point, I can probably lump you into one of three groups… 1) You don’t care or have no clue what this means 2) You care but think this means HP ‘has no NAC’… or group 3) You know about StillSecure’s success and ProCurve’s integration and think this is a great combination.

I’m sure everyone will have their own opinion- I happen to be in Group 3. Why? Because HP has taken the power of their servers, leveraged a very solid endpoint management tool and incorporated a variety of other management and security features by way of their identity management solution.

• The endpoint security. StillSecure’s Safe Access solution has been winning awards and earning stars for years. You can probably Google it, or check out some of Shimel’s blog  posts, such as this one, with 4- and 5-star reviews from SC Magazine. In fact, just this year (and in previous years) Safe Access was voted Best Endpoint Security Solution by SC Magazine and has won numerous other awards and accolades from various analysts and media firms. They have a clean, user-friendly GUI, a solid Linux platform and a variety of testing methods, deployment options and switch integrations. (And no, you don’t need ProCurve switches, the NAC integration is ready for your Cisco, Extreme, or whatever you have).

• User management. Combine one of the highest-rated endpoint security solutions with ProCurve switches, the #2 leader in the switching market (and Magic Quadrant resident) and the full integration with ProCurve’s Identity Driven Manager platform and you have one amazingly capable access control system. With ProCurve IDM, you can integrate directly with their NAC 800 appliance to offer per-user (or per-group) ACLs, QoS, restrictions or priviliges. Rules can be identity-based, time-based, location-based, or a combination of all. And, IDM eases 802.1X integration by offering users a central management and repository for user settings and VLAN assignments; it really is ProCurve’s special sauce and a distinguishing feature.

• Switch security. The integration of advanced switch security functions, such as DHCP snooping, Dynamic ARP protection and dynamic IP lockdown gives ProCurve another leg-up to fight common known attacks for both in-line and out-of-band NAC deployments.

• Zero-day protection. It gets better, the new Dynamic Configuration Arbiter (DCA) functions in ProCurve’s Pro-vision switches gives customers the unique advantage of integrating the NAC and IDM with ProCurve’s Network Immunity Solution (NIM). NIM uses flow analysis from sFlow and network behaviour anomaly detection (NBAD) to detect and automatically remediate on the edge. In English, that means we can use ProCurve’s NIM to detect attacks and take action at the edge port, such as blocking the port, locking out the MAC address of the offender, rate-limiting, or even mirroring the traffic to an IDS for further inspection. The super-nice part is, all the sFlow and NBAD works on wireless too. (Hey Stiennon, did you hear that?)

• Full integration. Unlike some of the other network-based NAC vendors, ProCurve has done an exceptional job of integrating these features and we’ll continue to see more integration in future revisions of the softwares and as more TNC/TCG integration frameworks are released (such as IF-MAP).

I think the strong integration with the infrastructure and the ability to leverage a mature endpoint integrity will make HP a ‘real’ player in the NAC market moving forward.

Not to knock other NAC solutions- Choosing a NAC is like selecting the perfect wine for your dish- there’s no 1 ‘right’ choice for all occasions. Each have their advantages and disadvantages. There are several that have special sauces and you’ll actually be seeing more on that soon…

# # #