IDS in a Virtualized Environment

[RSEngineer]

Can anyone elaborate on an IDS solution for a virtualized environment?

I   have blade servers running ESX/ESXi - heavily virtualized environment.   Im using blade switches as chassis I/O - no pass throughs.

The   requirement is to run an IDS service such that VM-to-VM traffic is   monitored. The traffic flow can be between two VMs on the same blade, 2   VMs on two separate blades in the same chassis, or two VMs on two   separate chasses...

In that case, I see 3 traffic flows off the bat...

same blade: vm-to-vm traffic is switched by a hypervisor switch (1000v or vmware vDS).

different blades in same chassis: vm-to-vm traffic will leave blade and be switched by chassis hardware switch (chassis I/O blade).

different chassis: vm-to-vm traffic will have to go to ToR (maybe even end-of-row).

NOTE: if VMs are on different VLANs, traffic will always go to end-of-row/agg switches (the L3/L2 boundary).

So   given all those possible flows, what is the best way to go about   deploying an IDS service? Placement? Virtual or physical? etc....

Thanks!

[michael_40catbi]

RSEngineer wrote:

Michael, but doesnt it become a management nightmare to have to manage hundreds of separate instances of virtual IDS appliances?

No.

Catbird provides you with a methodology of logical enforcement: Catbird TrustZones(R)

With TrustZones you manage your security policies for all of your zones, virtual machines, and virtual appliances from one place.

This is an area, automation, where we actively pursue competitive advantage.

Michael

Yes, I work for Catbird.

[Texiwill]

Hello,

Took me a while to get back to this thread....

IDS/IPS in a Cloud, absolutely want one there. Within a Cloud there is no real edge so you need to move network security tools closer to the networks you want to protect. This is a new way of thinking about network protections. With no 'big edge' anymore, the edge moves to the VM. So think of it this way:

Hybrid Cloud:

          |                      |

Enterprise| <-> Interconnect <-> | Private Cloud

          |                      |

I call this the dumbbell security model, thick on both sides and thin middle. So you need to absolutely harden the interconnect and ensure this is properly encrypted, etc. So perhaps you put IDS/IPS at the interconnect and that MAY work. But the problem is that if an attacker gets in through any number of ways (like a USB dongle) that IDS/IPs is useless. YOu are in the network. So instead of hardening at the edge, with the new type of threats you really want to harden/protect as close to the data and threat source as possible. Therefore I would put an IDS at both sides of the interconnect that has visibility into the virtual and cloud environments at a per VM level. All the tools I mentioned will do this.

Now consider Public Cloud it is more like an amoeba than anything so what can I protect, it has no actual edge, so you absolutely need to protect as close to your data as possible.

Remember with the new class of threats your detection needs to be close to the possible source as well as able to pick up anomalies almost instantaneously. I.e continual monitoring.

So yes, I would put IDS/IPS inside my virtual environment and all good ref architectures account for this using one of the introspection APIs. I would also consider puting DLP that close to each VM as well. In essence you want IDS/IPS at the vNIC level not the external switch uplink. The reason is that some network traffic may never be seen by the external switches. So vNIC is ideal, but if you cannot do that due to the use of tool, then vSwitch is better. pSwitch is never desireable for this type of network monitoring.

Depending on the tool you use, the management is not much of a nightmare, most federate their sensor platforms to a central management tool.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[michael_40catbi]

Taking off my vendor hat ...

Ed has a great diagram:

          |                      |

Enterprise| <-> Interconnect <-> | Private Cloud

          |                      |

I would generalize it a little bit:

          |                      |

Internal  | <-> Interconnect <-> | External Cloud

Cloud     |                      |

Now I'll add encryption technology: X*

            |                            |

Internal X* | <->*** Interconnect ***<-> | ***External Cloud

Cloud       |                            |

Encryption protects your data across the Interconnect.

On the internal side (X*) you need to have the ability to inspect the data/communications in the clear for data loss prevention, compliance, and other security purposes.

On  the external side (***) sensitive data should never be in the clear and even public data must have integrity and availability protection.

Camping on to Ed's other point: protection should be close to the data. In the cloud, putting protection on the perimeter is like leaving the condom on your night stand.

Putting that protection "near your data" will vary according to your internal and external cloud architectures. However the basic building code is well understood:

1. Protect the data at rest
2. Protect the data in motion
3. Protect the endpoint (VM, guest OS, application)
4. Secure privileged access
5. Secure user access
6. Secure VM to VM access
7. Audit the above
8. Continuously test that all of the above is working

You're on the right path as IDS is a necessary component for addressing several of the above requirements. Choosing a security technology should be based on the following:

1. Sufficiency -- the ability to meet your technical requirements (The faster, better part)
2. Cost -- can you afford it (The cheaper part)

Michael

[Texiwill]

Hello,

I think the dumbbell security model is interesting for several cases, but perhaps I should call it a multi-lobed model. WHy? Because I may have the following:

• Enterprise wholly owned by org.
• Hot site wholly owned by org.
• Private Cloud for burst capability (shared ownership)
• Software as a Service provider (not owned by me at all)

Aka:

                              SaaS

                              |

Enterprise   -----------------|---------- IaaS

                              |

                              HotSite

So I secure all the communication using encrypted tunnels between all these lobes.

I can put IDS/IPS/DLP/Data Security modules into the Enterprise/HotSite/IaaS

But I cannot put such into the SaaS ala sales force.

So what would I do?

Create a Security architecture that is Data Centric not location centric. Ensure that my data's integrity is maintained and if necessary its confidentiality while maintaining availability. Such a model would also include sensors for standard security issues but where the data lives or as close to it as possible.

What does this mean? Encrypt and Sign data regardless of where it has been or going to end up....

IDS/IPS/DLP still fit in to this model but there needs to be other early warning devices as the 'bad guys' have many attack methods, etc. The big question is how can I ensure sensors in the SaaS component?

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[VMN00bi3]

I appreciate everyone's in depth discussion of the concepts behind this topic. I'm just getting started here, and I'm trying to determine the best way to mimic a SPAN/monitor session to a vm running within a cloud.

Assuming I have a vm with some sort of traffic inspection software (snort, etc), can I just create a port group on vlan 4095 and assign my Snort vm's promiscuous interface to it? Will that effecitvely give me a basic mirror of all the traffic passing over the vswitch on all vlans?

[Texiwill]

Hello,

Yes that will work. You will need one per vSwitch up to 10 for vSphere 4 for a single snort appliance.

Best regards,

Edward L. Haletky

Communities Moderator, VMware vExpert,

Author: VMware vSphere and Virtual Infrastructure Security,VMware ESX and ESXi in the Enterprise 2nd Edition

Podcast: The Virtualization Security Podcast Resources: The Virtualization Bookshelf

[VMN00bi3]

Thank you for the confirmation!

[mila30]

To Texiwill:

You mentioned about other early warning devices, I just want to ask if what is the best warning device that I should get?   I know, there are advance methods that are existing in the net that could jeoperdize my system, any suggestions you can share?