Cloud Computing.com

Intrusion detection in a cloud computing environment

By Philip Cox

In this tip, the tenth and final entry in our series of technical tips on cloud security, we discuss the importance of intrusion detection systems in a cloud computing environment. Find out how intrusion detection is performed on Software as a Service, Platform as a Service and Infrastructure as a Service offerings, along with the available host, network and hypervisor-based intrusion detection options.

Attacks on systems and data are a reality in the world we live in. Detecting and responding to those attacks has become the norm and is considered due diligence when it comes to security. As a matter of fact, most of the standards and regulations applied in the technology space today have explicit instructions regarding the need for monitoring and alerting, or intrusion detection.

In this technical tip, we'll discuss some of the aspects of intrusion detection (ID) that should be applied in a cloud environment. We'll talk about where ID can be applied and by whom, as well as some future ID paths that should be used when available.

Intrusion detection and your cloud computing model
The ability to perform ID in the cloud is heavily dependent on the model of cloud computing you are using:

• Software as a Service (SaaS): The reality is that SaaS users must rely almost exclusively on their providers to perform ID. You may have the option of getting some logs and deploying a custom monitoring and alerting on that information, but most ID will be done by the provider.
• Platform as a Service (PaaS): Like SaaS, most of the ID for this level of service will be done by the provider. Since intrusion detection systems (IDS) are typically outside the application, you must rely on your provider to deploy IDS in a PaaS. You can, however, configure your applications and platforms to log onto a central location where you can then set up monitoring and alerting (i.e., where you can perform ID).
• Infrastructure as a Service (IaaS): This is your most flexible model for ID deployment. Unlike the other two, IaaS gives you more options as a consumer. This is where we will spend most of this article.

Intrusion detection for IaaS: Where should it be performed?
We need to identify the locations that should be considered when thinking about ID in the IaaS cloud. I see four primary "spots":

• In the virtual machine (VM) itself: Deploying ID in the VM allows you to monitor the activity of the system, and detect and alert on issues that may arise.
• In the hypervisor or host system: Deploying ID in the hypervisor allows you to not only monitor the hypervisor but anything traveling between the VMs on that hypervisor. It is a more centralized location for ID, but there may be issues in keeping up with performance or dropping some information if the amount of data is too large. Furthermore, as we will see, this space is very immature at this time.
• In the virtual network: Deploying ID to monitor the virtual network (i.e., the network established within the host itself) allows you to monitor the network traffic between the VMs on the host, as well as the traffic between the VMs and the host. This "network" traffic never hits the traditional network.
• In the traditional network: Deploying ID here allows you to monitor, detect, and alert on traffic that passes over the traditional network infrastructure.

Who is responsible for intrusion detection in the cloud?
One thing to confirm right away is who will be responsible, and how they will be responsible, for ID in the cloud. I see the following as basic rules:

• Providers will deploy ID in certain locations that feed into their (not your) IDS.
• You must have a service-level agreement (SLA) in place that require providers to notify you if you are affected directly (i.e., they see attacks against your VMs) or indirectly (i.e., they see attacks against a hypervisor that is running your VMs).
• If and when you deploy ID, it should integrate (in some manner) into your current monitoring and alerting infrastructure.
• It is likely that the future will have third parties that provide IDS for the cloud, and that this will just be an add-on cost for those who do not want to manage ID in their cloud instances.

Performing intrusion detection in the cloud
So now that we know where we should/can perform ID in the cloud, we can ask, "How do we do it?"

A traditional host intrusion detection system
The first option is the traditional host intrusion detection system (HIDS). You can use a HIDS on the VM, as well as the host/hypervisor. The HIDS on the VM would be deployed, managed and monitored by you. The HIDS on the hypervisor would be the responsibility of your provider. If you desire to incorporate any of the hypervisor ID information in your IDS, then you would have to coordinate with your provider. In reality, it is likely that you will not get that information, so the contract with your provider will need to ensure that they are performing adequate monitoring and alerting.

Deploying and managing a HIDS on the VM would be the customer's responsibility, while HIDS on the hypervisor would fall under the responsibility of the provider.

A traditional network intrusion detection system
A second option is a traditional network intrusion detection system (NIDS). This type of deployment is useful in detecting some attacks on the VMs and hypervisor. It does, however, have several limitations. The first is that it cannot help when it comes to attacks within a virtual network that runs entirely within the hypervisor. Second, it has very limited visibility into the host itself. Lastly, if the network traffic is encrypted, there is really no effective way for the NIDS to decrypt the traffic for analysis.

In the cloud, NIDS falls completely in the realm of the provider to deploy and manage.

A hypervisor-based intrusion detection system
The third option would be the use of an intrusion detection system that runs at the hypervisor layer but is not strictly a HIDS for the hypervisor. One of the promising technologies in this area is the use of VM introspection. This type of IDS allows you to monitor and analyze communications between VMs, between hypervisor and VM and within the hypervisor based virtual network. The advantage of hypervisor-based ID is the availability of information, as it can see basically everything. The disadvantage is that the technology is new and you really need to know what you are looking for.

As with NIDS, this falls completely within the scope of the provider to deploy and manage.

In conclusion
In reality, intrusion detection in the cloud is best performed by the provider. They have the hooks where the important stuff happens. ID based on VM introspection is probably the most promising technology on the horizon in terms of an instruction detection system for the cloud. I would go as far as to say that it is the future of cloud IDS, and that means that you will have to have a good SLA with your provider to ensure they are providing the timeliness and information you will need.

If your provider is not offering ID as a part of their service, you should strongly encourage them to begin, or even find another vendor who will. When it comes to the long-term, standards, compliance and best practices will require you to have an effective IDS. It will not be an option, and any cloud provider who cares about security will be offering this service.

ABOUT THE AUTHOR:

Phil Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security.

His experience includes Windows, UNIX, and IP-based networks integration, firewall design and implementation and ISO 17799 and PCI compliance. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance with PCI-DSS. He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing).

Phil holds a BS in Computer Science from the College of Charleston