I’ll take your 6 centers of excellence and uh, raise you 2 data centers. Following up on the HP announcement that they’ve partnered with Yahoo and Intel to create cloud computing Centers of Excellence this week, IBM said they were building out 2 data centers to accommodate the coming cloud computing resources need. I should say that IBM had already announced their “partnership” with Google to provide services for the cloud back in May. Who’s left to partner with on cloud computing? Microsoft and Amazon?

Packet Trap Networks recently conducted a survey of network engineers and IT professionals who perform network management duties inside companies with more than 100 employees. Out of the 800 engineers surveyed, 49 percent stated that they did not have a comprehensive network management system in place – showing a need for solutions focused on the mid-market – i.e., the right features at reasonable prices. If you remember, Sevcik and Wetzel (not a vendor!) conducted their own survey on application performance management and had similar findings but a rather different answer… (hint – starts with “E” and ends in “7”)

Is open-source software more secure? After all thousands of eyes are better than a handful, right? Well, according to a report sponsored by Fortify Software, that’s just not the case. Roger Thornton, founder and CTO of Fortify Software, adds that the underlying problem is “a lack of understanding and collaboration between developers and security experts – today each are talking past each other when it comes to security.”

For all you aspiring CIOs out there, WSJ has provided a must-read list. Uh oh– the first on the list is “How to Read a Book”. Please, any negative comments directly on the Journal site…and any “good” ones here!

ShareThis

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

“PCI Risk Management”

Now usually when I see a term like this, I can only imagine that such things are the byproduct of rapidly decaying brain cells.  In my mind I imagine there’s a conference room somewhere with some marketing types all hopped up on the vapors from industrial solvents spewing terms like “protectivity” or “advanced adaptive deep packet inspection” into the ether with all the acumen of an intoxicated long-horned bovine.

BUT

I thought about this, and it’s really not a bad idea - depending on how you define it.  Now I just couldn’t make the effort to read how the author used the term (I have a short pain threshold), but here’s my thoughts on what PCI Risk Management should be.  If we define Risk as the probable frequency and probable magnitude of future loss.

Then managing the risk inherent in PCI DSS compliance could mean:

1.)  The expected frequency of being out of compliance and how much that will cost us.

Because let’s face it - being in or out of PCI compliance is still a subjective judgment.  First, we have what our ever-qualified assessor says.  But in the case of an incident, it’s really someone else who has the final say in whether or not we were “compliant” at the time of incident.  So we can only know for certain if we’re in compliance after the fact - i.e. after there’s an incident.  So if we cannot really “know” if we’re compliant - we have a probability problem to solve!  Sounds like “risk” or “secure” doesn’t it?

So we could view the PCI as a threat community to deal with.  This gives us the first angle of what we could call PCIRM (this sort of term begs to be it’s own acronym, doesn’t it?) - the simple creation of a probability statement that says there is some belief that we could be found out of compliance - regardless of our efforts - and the calculation of what the impact would be to our organization (like defending frivolous 90 bajillion $ law suits from tiny financial institutions whose lawyers smell blood in the water).  Note that you may or may not want to add the value of the money and time spent on PCI compliance into your loss magnitude calculations.  It’s a sunk cost at that point.

However, there’s another side of the coin.  We can find out the risk of being out of compliance, but is there risk in being *in* compliance?  I think there is.  So our second aspect of PCI Risk Management might be:

2.)  The expected frequency of being in compliance and how much that will cost us.

An alternate view of how we could view the Payment Card Industry as a threat community would involve trying to figure out the probable frequency with which they will make onerous demands of our security budget, and the impact of those demands.

Now note that we would have a “secondary risk” to measure here.  I’m thinking that it’s not improbable that our PCI efforts may not be the most efficient use of or time and money.  So if we’re spending money on what PCI says we must, and neglecting areas of our IRM landscape that would actually reduce organizational risk more than those PCI efforts - then PCI compliance is costing us some real value by reducing our capability to manage real risk.  However,  and it’s quite a long tail event but, imagine that we’re unlucky and an incident happens!  This incident may become, in no small probability, the byproduct of PCI requirements.  Being diligent in risk management, we might want to study this likelihood, too.

So there you have it.  In both cases PCI Risk Management involves looking at the Payment Card Industry as a threat community, and determining the probable impact of having to deal with PCI DSS.

Now if you’ll excuse me, I have a white paper to write and I’m fresh out of acetone-based paint remover.

POST SCRIPT

I should make it clear that Risk Management should (and is) obviously being performed by those with PCI concerns.  PCI, if you will, is simply a sort of ISMS.  And the development of an ISMS can assist IT management with the process of developing metrics and analysis concerning the organizations capability to manage risk.  There’s nothing wrong with PCI in this regard.

But I figured I should make the effort to read what the author was advocating, and the document this “PCI Risk Management” term was drawn from was really a set of “best practices” for PCI and “best practices” above and beyond what PCI requires.  This is not risk management (and no, adding “risk assessment” - in quotes because the author is really referring to vulnerability management - to the list of best practices doesn’t make it risk management, either).  It is more witch-doctory.

AEP had been a victim of the NAC fallout.  They made a bad bet on an OEM partner to provide them with NAC technology.  When that NAC vendor went belly up, so did AEPs NAC product as a result.  Now Tim Greene reports that AEP has come out with a new device that while not strictly a NAC product, does more identity access control and does not seem to do any admission control.

AEP which makes a SSL VPN type of appliance has a new appliance that delivers an agent to an endpoint and authenticates the user.  It than according to the article inserts an identifier in the payload of every packet that shows where and who that packet is from which then allows it to either pass or not pass through, only to its allowed base.  I don’t know that seems a bit of a chokepoint/bottleneck to me, but I don’t know enough about it, only what I read in the article.

The appliance is not cheap with a price tag of over 50k for just 99 users.  It seems like an awful lot of money for what it does.  An important lesson I think on picking the right OEM partner.  Pick the wrong one and your product goes down as collateral damage to the OEM partners demise.

From Snort.org:

We’re pleased to introduce our first beta release built on the new Snort 3.0 architecture. The Snort 3.0 architecture consists of two primary components: a software platform called the Snort Security Platform (SnortSP) 3.0, which is shipping in beta form in this release, and traffic analysis engine modules that plug into SnortSP. This beta test release contains one engine module which contains the Snort 2.8.2 detection engine implemented as a SnortSP engine module. SnortSP is an open-source platform for running packet-based network security applications. It provides many of the common functions required by programs that deal with packet processing such as configuration loading, event generation and traffic logging, data acquisition, protocol decoding and validation, flow management, and more.

They provide you an opportunity to provide feedback on the beta release as well “sspneta SHIFT 2 sourcefire D0T com”.

Downloading my copy now.

Article Link

Dear network vendor,

As someone that is forced to configure and implement security on your hardware, I would greatly appreciate stable code and properly functioning features. Unfortunately, I cannot always choose the hardware my customers are using in their infrastructure. However, if you would like for me to recommend they continue purchasing and using it, then the product must demonstrate to me that it is: capable, reliable, predictable and well-documented. If your product is not meeting these requirements, I’m forced to recommend other solutions to your (current) customer.

Stable Code. If I have to spend 2-6 hours per implementation working through your product’s bugs, and then must either spend time on a support call or spend time getting packet captures to prove to you it’s not working, I am not a happy camper because you’re slowing down my progress. Your customer is not happy because they’re paying for that time and I’m not cheap.

Features. Don’t publish in technical documentation that your product, or code can do something, only for me to find out later that it cannot. On-site in the middle of an implementation is not the time to architect Plan B. Let me know before, either through technical docs, white papers, best practices or release notes. I do read those. If you want to bend the truth, do it the marketing fluff, not my technical documents.

Documentation. If your product does do what you say it does, then please do document and explain the concepts and procedures. Examples are good, but explanations are mandatory. A correct CLI reference is always lovely as well. If there are got’chas or tricks, please also document those. Again, white papers or release notes are fine. Having to track down the one security engineer from your company that holds the magic key is not practical, nor scalable. Plus, he may be on vacation during my install, which would make me irate.

Support. If your product is not functioning or performing as expected, do NOT expect your customers to have a current maintenance contract to address a known issue or bug (or an un-known issue or bug for that matter). If they found a bug for you, you should probably give them a maintenance contract for a year… or two. If you don’t let us call support, I will find one of your pre-sales engineers and we will use him or her for post-sales support, which is not what you want them to do. But that’s your problem, not mine.

I believe that sums up the major issues. Specifically, I am interested in security, RADIUS, SSH, SNMP, DHCP and 802.1X functions. Before you add another bell or tweak another whistle, please make what you have works… consistently. That should be first, so it’s my Feature Request #1.

Respectfully,

jj

# # #