Securing Applications in Amazon Web Services
One of the key reasons customers are moving applications to AWS is the near-instant scaling capability and cost savings versus maintaining their own dedicated environments. This applies not just to the applications themselves, but also the security solutions protecting them. Our SecureSphere for AWS design partner went live for the holiday shopping season expecting to need between 4 and 8 virtual gateways. As it turned out, they had a phenomenal product launch and ended up needing to scale to 120 virtual gateways. Which they were able to do in a matter of days. Now, we are proud of the ease of deployment of SecureSphere, but in a physical environment, deploying 120 gateways would take months simply due to the physical friction associated with hardware installation, maintenance windows and other factors.
As a part of our marketing efforts for the solution, we’ve been talking to many Imperva customers and prospects about the solution. And one of the most common questions we get is “How do the different Imperva cloud solutions fit together?”
Our approach to the problem of securing cloud workloads is intentionally broad. Just like on premise data center security, there are several different important aspects of cloud security. We are building out a set of frameworks we’re calling reference architectures for different key use cases and you will see us release these over the course of the next few quarters. But for the moment, let’s focus on applications deployed at Amazon Web Services. Our reference architecture will go into much more detail, but the approach actually breaks down quite simply:
For traditional WAF protection, customers can choose between SecureSphere WAF for AWS or the WAF capability offered by Incapsula, an Imperva company that offers a SaaS service that delivers WAF, DDoS mitigation, content delivery and load balancing (as a side note, while SecureSphere for AWS is new, Incapsula is agnostic to where applications are hosted and happens to be protecting more than 500 customers running on AWS). There are two main factors that we see driving this choice. First is deli very model preference. Incapsula if the preference is service oriented, SecureSphere if the preference DIY. The second is integration needs. SecureSphere has grown up in the enterprise data center and it has a very healthy eco-system of product integrations many enterprises expect and want to replicate in the cloud. Incapsula has grown up as a cloud service and doesn’t yet have the full spectrum of these integrations.
For Denial of Service mitigation, the choice is fairly simple: Incapsula. They’ve built a global network with the resilience to handle today’s 100Gbps+ attacks, but also the operations to deal with multi-vector DDoS attacks. In other words the combo volumetric and application layer DDoS that’s becoming the norm. SecureSphere can help with application layer DDoS mitigation, but to combat multi-vector attacks, you really need a cloud-based service.
Finally, what many customers overlook is the need for strong security on the AWS administration console. The consequences of a failure here can be pretty dire. For sure, every customer should be using Amazon’s built-in two-factor authentication capability. You can even integrate with your own SAML gateway. But we believe best practice is to also deploy a solution for auditing privileged users and preventing account take over. Which is where Skyfence comes into play. Skyfence solutions provide visibility and control over cloud applications...and the AWS management console happens to be an example of the criticality of their privileged user monitoring use case.
In the coming months, we will be generating a bit more depth on this topic as well as a few other variations of dealing with the cloudification of the data center, so stay tuned…
Authors & Topics: