Last month, I met James (name changed) while at AWS Summit in London. As I was managing Imperva’s booth, he walked over to me with a query about what we do. A conversation ensued and James described his company for me. They were into financial-legal intermediation between underwriters, insurance brokers, and customers.
As it turned out, he was at the event to deep dive into the Amazon API Gateway plus AWS Lambda service model. He explained that use of Lambda should allow them to cover additional real-time intermediation cases that are very common in the financial-legal industry. In addition, the AWS Lambda cost model made a lot of financial sense to him.
So, I asked…how did he plan to secure his public presence?
To my mild surprise, he had not considered security—most financial customers in a public setting would require provable security controls by default. He also had not put much thought toward the “public” part of the API gateway. The fact that, as of today, AWS offers their API gateway as a managed service offering makes it very simple for application developers as AWS takes responsibility for deploying and managing the application stack for them. On the other hand, it creates challenges for enterprise security teams as API gateways cannot be contained inside a VPC (a defacto model for most customers).
We ended things with me sharing information with him about how our application security offerings (SecureSphere and Incapsula) could help secure these new applications. Turns out, I’d have several similar conversations throughout the day like the one I had with James.
Microservices, Developers, and a Say in Security
As the day progressed, I had the chance to chat with multiple DevOps and security folks. I observed two trends:
- One, most developers or DevOps folks at the AWS Summit were either currently using or notably interested in using microservices architectures. Containers and API gateways were the tools of choice for such architectures.
- Secondly, development teams had a stronger say in the choice and deployment model of application security technologies. At the very least, they wanted an integrated app+security deployment approach.
Both of these trends have a strong business context. In certain cases, both container and API gateway (Lambda-based) approaches are cheaper to run versus EC2-based application instances. And the microservices approach emphasizes independence between multiple business units while allowing them to scale independently to the needs of the business. (Note: Azure also offers API gateways powered by Azure functions, similar to Lambda).
How Imperva Customers Secure API Gateways and Containers
Imperva customers are using our products today to secure containers and API gateway deployments (with or without microservices):
- API gateways can front end a virtual application instance/container deployment or, in the case of public clouds, a Lambda/function-based deployment. In both cases, customers are using either our instance/appliance-based (SecureSphere) application firewall or our cloud-based application security solution (Incapsula) to secure the gateway.
- On the other hand, securing containers is similar to securing virtual instance deployments. Many Imperva customers have successfully secured container deployments with SecureSphere or Incapsula.
With our focus on ease of deployment, API coverage, and a wide range of virtual/physical appliance capacity, Imperva ensures customers are able to accommodate developers’ interests and requirements while implementing the necessary security controls for the business.
In my role at Imperva, I continually listen to our customers, observe security trends and share what we learn as a team. Perhaps we’ll have a conversation ourselves one day soon. Until then, look for more from us here on best practices for securing microservices and ways Imperva can help.
Try Imperva for Free
Protect your business for 30 days on Imperva.
