February 3, 2014 | Written by: Chenta Lee
Share this post:
As the prominence of software defined environments grows in tandem with new vulnerabilities in the virtual environment and the new technologies to secure the virtual assets, picking up an adequate deploy pattern for your security services will become critical to increase your return on investment (ROI). Security services in the cloud include the intrusion detection system (IDS) or intrusion prevention system (IPS) service, firewall, data leakage prevention (DLP) and so forth.
The deployment pattern of security services would vary depending on the targets you want to protect. An inadequate deployment would not only result in usability issues but could also bring potential threats to your virtual assets. On the contrary, a well-defined and integrated deployment pattern helps the provider gain confidence from its cloud service. In this blog post, we categorize the essential components of a cloud infrastructure related to security services. Furthermore, in order to purpose a proper deployment pattern, we classify two types of models for deploying security services.
The essential infrastructure as a service (IaaS) components related to security services are:
The computing module could dynamically deploy a virtual security appliance to your tenant. Moreover, the security service could leverage the computing module to monitor and control the lifecycle of virtual machines (VMs).
The network module could make a network as a service by leveraging Software Defined Networking (SDN) technology. The security service needs to talk to the network module to route a certain flow from certain VMs to it to provide security. In addition, we could easily isolate a VM by changing the network topology dynamically.
The security service needs to know who is using the VM in order to apply the appropriate security policy to it. Plus, the security service needs to filter the information that it can show to the user from different tenants.
The following are two models for deploying security services:
Security service for tenant
The customer could build a tenant and run its VMs in an independent environment. When the customer wants to deploy a security service on it, they want to deploy it to the entire tenant. In addition, different tenants would have different requirements for security services. For instance, company A and company B each build their own tenant from the same public cloud provider. They both want intrusion prevention, but company A also wants to enable IP reputation filtering.
Security service for VM
The user could request new VMs from the cloud provider. The VMs owned by different users are in the same tenant; however, each user would have different requests for protecting his VMs. For instance, an individual developer requests a web application firewall for his VM in a public cloud.
The preferable deployment pattern for deploying a security service to tenants is to deliver your service in the form of a virtual appliance. In the following diagram you can see that every tenant has the security service running inside a virtual appliance. The computing service takes charge of deploying the virtual appliance. After the service is deployed, it needs to talk to the networking service to modify the network topology in the tenant in order to route certain traffic to it. When applying a security policy to the VMs in the tenant, the service needs to talk to the identity service to get the proper policy. Hence it could provide meaningful information in its management console. For example, the service could map the IP address to a user name.
The advantages of this pattern are:
If two tenants share the same physical appliance, how could you guarantee the segregation of tenants? The truth is that all the data and traffic from different tenants is aggregated in the same physical appliance. Using a virtual appliance, the service we deployed is dedicated to that tenant only; therefore it is impossible to leak data to another tenant. Moreover, when users access the management console, they could see nothing but the information from their own tenant.
Every physical appliance has hardware limitations. For instance, the IPS appliance has a port number limitation, so you could only protect a certain amount of network segments. The hardware limitation makes it hard to scale up; however, a virtual appliance has fewer limitations. You can always add a new port to it or even deploy a new virtual appliance to share the load, which makes your service easy to scale.
Better charging model
A virtual appliance has some unique charging models. First, we could charge by capacity on demand (CoD). Depending on the size of the tenant, we could deploy different sizes of virtual appliances to fit their requirement. Second, we could charge by the processing power consumed by the service or the network usage of the service. Since everything is virtual, we could precisely know the amount of resources used by the virtual appliance. How could you do that if tenants are sharing the same physical appliance?
The deployment pattern for deploying security service to a virtual machine is more flexible. We could use either a physical appliance or a virtual appliance. The key point is how to enable and disable the services in each individual VM. In the following diagram you can see that the service needs to talk to the networking module to make sure that only the VMs enabling the service will be connected to it. Of course the service still needs to talk to the identity service in order to apply the correct policy to VMs.
In this blog post we talked about the deployment patterns from a very high level. Those patterns need to be modified based on real-world scenarios, but the key concepts are still the same. You can see how your security service will interact with cloud components, and you also learned the pros and cons between using a virtual appliance versus a physical appliance. Which deployment pattern would you like to use? Leave a comment below.