Incapsula, acquired by Imperva in 2014, is a cloud security and acceleration service. The Incapsula network has grown to 26 PoPs, with more planned. Although Incapsula started around the same time as CloudFlare, their business models are different, as we’ll discuss in a later post. Incapsula is one of the pioneers of the Cyber Security CDN business model. The Cyber Security CDN is focused on providing an advanced cloud security portfolio of products and services that runs over a global CDN infrastructure. A big thanks to Marc Gaffan, General Manager of Imperva Incapsula, for the interview.
What does Incapsula offer to its enterprise customers? It’s a cloud service that helps companies deliver their applications more efficiently and securely than existing solutions. Within that – there are four core sub-services we offer: a CDN, application security, DDoS mitigation and load balancing. At a high level, our service accelerates the delivery of web applications and protects those applications from external threats and attacks, leveraging a multi-layer approach and product set.
Who is your biggest competitor, particularly in the Fortune 1000 accounts? What’s your competitive advantage over them? I’d say that the company we run up against the most is Akamai, especially in the enterprise segment. We believe that our security is superior and we can handle the content delivery requirements of most any large company. We have many Fortune 500 companies that are already using our services. From a capacity perspective, we are absolutely able to handle very large sites and give them what we need. When it comes to security, I’d argue that Akamai can’t rival us.. We are a security company first and foremost. That means that our web application firewall technology is the best in the industry.
We built our web application firewall from the ground up to be used in the cloud and to push out the rules very quickly. Akamai, by contrast, took an open source solution, Mod Security, and retrofitted it to the cloud. They had to make a lot of compromises in what they could turn on and turn off because of the limitations of the open source package and single tenant architecture, creating a high rate of false positives. An Akamai customer has to go through a professional service organization to create rules, which slows down the process. The turnaround time is a non-starter for a lot of businesses.
Now that Akamai has acquired Prolexic, couldn’t they also offer a similar hybrid solution? The difference between Incapsula, Akamai and Prolexic is that we are offering acceleration and security on one network within one stack – as opposed to two different systems. Initially, Akamai built a CDN and used its CDN infrastructure to deflect DDoS attacks. Prolexic built a DDoS mitigation service with a few scrubbing centers. Then Akamai acquired Prolexic, and now you have two separate stacks built for different purposes, which Akamai is trying to integrate into a single cohesive system. Whether that is feasible or not remains to be seen.
How does the Incapsula approach to DDoS mitigation compare to that of other CDN providers? Some of our competitors have built hundreds of PoPs with thousands of servers at every Internet exchange, connected to most ISPs, and they try to solve the DDoS problem by absorbing entire attacks. Other companies have built a DDoS mitigation scrubbing platform using a silo approach, which means they built a few scrubbing centers, bought lots of bandwidth and servers, and they scrub the traffic without accelerating the content.
From an infrastructure perspective, we have 26 data centers across the globe, and continue to add PoPs at regular intervals. Our architecture is designed with a hybrid approach in mind, where we built our global network to address the requirements of application security, CDN and DDoS mitigation. You can think of what we do as elastic. We can move traffic around dynamically, creating virtual scrubbing centers from as several PoPs. Since each PoP is also designed to accelerate traffic, the end result is seamless mitigation with no perceptible slowdown in performance for the end user. We believe that this approach is better suited to the needs of today’s enterprises.
Doesn’t a smaller number of POPs affect coverage and performance? When we built our network back in 2009, the performance problems associated with the last mile were solved. When some of our competitors built their services 15 years ago, people connected to the Internet via modems, and DSL was just being introduced. Today, there are home users with 100 megabit per second connectivity.
In addition, peering, BGP routing, and global network architecture have improved vastly since to 2009. We live in a very connected world, especially at the backbone level. Therefore, there is no longer a need to build thousands of PoPs in all corners of the world, in order to provide fast application delivery. Instead, we built a global network of SuperPoPs strategically located at various IXC’s, connected to Tier 1 ISPs. Based on our research, we are 5ms – 10ms away from 95% of the world’s internet population.
How does your security approach benefit clients? Our web application security platform was built from the ground up to scale, on a global basis, where rules are pushed out within 30 seconds or less. Our CDN, WAF, and DDoS Mitigation platform runs on a single network, architected and streamlined to work as a cohesive unit, unlike competitors that use separate systems, patch them together, and call that a solution.
Our network is built on a Software Defined Network Security model and architecture, where we use the power of the network and a cohesive security application stack to deflect application and DDoS attacks. Not only is this approach superior to other cloud security services, but its far better than deploying dedicated DDoS appliances, which are limited in terms of scale, scope, performance, and not to mention, very expensive.
DDoS Mitigation – When it comes to DDoS, there are three different tiers of providers. One tier includes companies like VeriSign, Neustar and Arbor Networks that have been around for many years. These cater to large enterprises, and are expensive. Then we have CDNs with DDoS scrubbing capabilities such as Akamai, EdgeCast and Limelight. Next, there are appliance companies that bought or built their DDoS Mitigation capabilities like F5 and Radware. Finally, we have the small pure-play DDoS Mitigation providers that have a few scrubbing centers, yet don’t have an ASN.
What makes Incapsula’s DDoS Protection better than the competition? Our primary focus is on enterprises and large-scale online businesses. You could have a 200 to 300 person organization whose business is entirely online. They’re generating over $200M a year purely from an online perspective. If they get attacked, they could lose a lot of business, so they always need an immediate response. On the other hand, you get enterprises that need an enterprise wide solution that is more of a hybrid between online and brick and mortar.
There are a couple of things that we do differently for DDoS protection: a) our solution is broader than any of the providers you just mentioned. We’re able to provide three layers of DDoS Protection: web properties protection, which is a robust combination of CDN, DDoS mitigation and the application security. The other is the DNS protection (what we call Name Server Protection). The third is to protect a company’s entire infrastructure directly at the IP level. That’s by definition an enterprise solution. You need a full subnet and BGP capabilities to be able to route traffic when you get attacked to make it a workable solution. From that perspective, we’re unique.
A new service that we launched this quarter is what we’re calling “dedicated IP protection.” That means if you’re an organization without your own subnet or ASN, you could receive an IP address on our network that will provide a gateway to yours. That will be the IP address that the external world will use to be routed to your IP address. All traffic will get routed to us. It’s an infrastructure level protection plan for those who don’t have full BGP or ASN capabilities at their disposal.
That’s a breadth of solution, which I don’t think any other provider in the industry today can provide. Most DDoS attacks today are multi-vector and target multiple parts of the infrastructure, such as a combination of an application attack and a volumetric attack. Enterprises required comprehensive protection to cope with all kinds of DDoS attacks.
Most CDNs have the network capacity to absorb volumetric DDoS attacks. How does Incapsula deal with application (Layer 7) attacks? Layer 7 attacks are often invisible to network monitoring due to their relatively low volume; however, most applications cannot sustain 1,000-5,000 requests per second. The web servers will crash, as will the database, depending on what query they’re running.Say you have a search function on your website that goes all the way to your database in the back end, you need a way to deal with a high volume of search requests so that your website doesn’t shut down. We’ve seen a lot more of these kinds of attacks.
They are much harder to deal with. Applications are becoming more complex and the layer 7 attacks are also significantly growing in sophistication. This is typically where bottlenecks occur. They are generating what seem to be legitimate requests; the challenging part is how to distinguish between the legitimate and malicious requests bombarding you during an attack.
That’s where our technology comes in: we’re able to identify 99.5% of all requests through the source. We know if it’s a browser and if it’s a bot (and whether it’s a good or a bad bot). That’s even before we look at what the request is trying to do and figure out the behavioral pattern. At first sight, we can identify the vast majority of requests and stop them from gaining access. That’s what’s most important when dealing with these kinds of application layer DDoS attacks.
How does your hardware compare to appliance-based vendors? One more thing that makes us very different from many of the providers you mention is that our mitigation hardware is home grown. We developed a very unique appliance, which is a single appliance that can scrub 170 Gigs of traffic very effectively through very new Intel chipsets, SDKs and silicon technology that we’ve built into a custom appliance, codenamed Behemoth. Using a software-based approach, Behemoth allows us to push out new technology and mitigation techniques within hours, which allows us to respond to new threats much faster than other DDoS mitigation services.
Are you saying that your Behemoth DDoS scrubbing servers are better than Arbor Networks and Radware Hardware appliances? Yes, they are based on two year old technology compared to ten year old technology. They give us a much faster turnaround time in terms of security updates and security rules. Security has changed a lot over the last ten years. People thought ten years ago that if they had the best perimeter defense or the best solution in the market, they’d be safe. Security practitioners have come to the realization that they will get attacked; what they have in place will be circumvented and breached.
What they need is to be very agile. That’s where security people are moving to today. They will be hit by something they and their vendors have never seen before, and they need to be able to react quickly. We provide them with the ability to react to unknown threats within just hours, while it might take the hardware providers weeks and possibly even months to implement a solution and then get it rolled out across the entire customer base.
Can you be more specific by giving an example of a particular situation? Let’s look at different elements of an attack without going into a hacker level of detail. Every single security mechanism is built by looking at a number of parameters, which are typically hard coded; you typically have a software layer that’s correlating those parameters and trying to figure out what type of attack it is, and how you mitigate it. Making changes in the heuristics or the rules based on those parameters, typically software, can be updated very quickly.
However, if you have to start adding different capabilities by looking at different parts of a packet and doing changes in hardware that will require you to look at other elements of the attack, you’re fairly limited. You’ve typically got to do hardware changes and/or firmware updates. There is a lot of software that’s been coded into the hardware. What we’ve done is essentially abstracted everything into the software level. This means we can react at software speed; and because it’s a service, we can react at DevOps speed because we push out new software across the entire network. The whole development cycle and providing something on premise can mean you go through a lot of testing. It’s a classic difference between a shippable product and a service.
We can also make adjustments very quickly. That means if we deploy something, and we see that it’s overblocking or underblocking in response to real traffic, we can update it quickly. Compare that to a scenario in which the hardware has to get shipped out to customers, and only then do they see the effects of the new firmware. It takes time for people to realize that it’s underblocking or overblocking because the sample set is too small. We see millions of HTTP requests and IP addresses in minutes. The whole development, rollout and correction process is something that we do by ourselves and we can adapt very quickly because it’s all software.
Application Security – In general, we offer a multi-layered security service to customers. We start with a basic access control list, where customers can select which countries are able to access the applications. Then, we protect against automated bot attacks. We identify who are the attackers, and keep them out. Some of these attacks are security concerns, and others are operational concerns. Our market leading web application firewall enables the customer to configure security policies at a very granular level.
Our design goal is “30 second security rule update” that is propagated across the planet. That means customers can set up a rule in their dashboard, and the rule will be propagated throughout our global network within 30 seconds. Our competitors take as long as 60 minutes to push out security rules across the entire network. With some providers, fine-tuning is required. That means it must go through 1 or 2 iterations before it is propagated through the CDN infrastructure. Translation – that means customers will bleed under attack for 60 to 180 minutes. When it comes to DDoS, we offer the most robust DDoS security suite. We offer every type of DDoS mitigation service that is available today.
Many offer WAF protection, which protects against known threats. Does Incapsula offer protection against the unknown zero day threats like a FireEye would? No security company, knows what’s coming tomorrow. The way we protect against zero day threats is by leveraging the cloud to push out new security rules very quickly to our clients. We have a 24/7 security operating center team who are looking at emerging threats and we are constantly updating our rules. We update our rules on the service 2-3 times a week on a routine basis, sometimes several times a day if there is a WordPress or other common platform vulnerability outbreak.
2014 was a very eventful year when you look at Shellshock, Heartbleed, and other exploits. All these zero-day vulnerabilities were patched on our service within hours. Thousands of customers woke up in the morning and heard about Heartbleed. By the time they got to the office, their infrastructure was virtually patched because they’re sitting behind our infrastructure. This type of agile security is what our service is all about.
You mentioned that many attacks nowadays are against the applications, and are highly sophisticated. Let’s say a well funded hacker hires 5,000 people to launch attacks on a website. Each attacker is a human being, and their online behavior reflects that. How can Incapsula protect against a manual bot army. There are multiple layers in that answer. I can tell you that the technology we have is divided into multiple layers. The first layer is essentially signature based. We’ve developed a unique signature engine that includes hundreds of parameters. When we see a request coming, we know how to classify it (if it’s Chrome, Explorer, Firefox etc. and what version it is), absolutely not by what it’s telling us. There’s a user agent string that the client will send to the server to tell them what they are. We can see that if someone says they are using Internet Explorer 9, and they’re not, we can detect it.
That’s why these kinds of attacks get treated immediately at a higher level of suspicion, even to a level that they will get blocked immediately. That’s when we start looking at what they’re doing. Are they posting the same requests at unreasonable velocity? Are they coming from IP addresses that we’ve seen used foully in previous attacks? We cross-correlate IP addresses across hundreds of thousands of websites. We’re able to map out the botnets on the Internet and keep them up to date.
Can you give me an example? Say that task force of 5,000 people that you spoke about attacked an existing customer of ours and we were unable to detect what they were doing automatically because they were all using real browsers. They are humans but they’re hitting a specific application in a way that’s impacting the customer. Our security operations center would start working with the customer and would figure out that the most vulnerable part of the application was being attacked. We would then create behavioral rules to identify an attack on that specific area in the application.
Then we would identify the IP addresses of those 5,000 IP addresses of the people that were hired. Two days later, that same 5,000 group would get hired by a different attacker to hit another Incapsula customer. Now we have information because we’ve seen those same IP addresses used in a bad way two days ago. You wouldn’t even have to look at what they’re doing at the application level. The fact that we use these types of correlation and new network technology to cross-correlate between different websites creates what we call a cumulative learning curve for all our customers.
All our customers are learning about the threats together. They’re actually not doing anything, but by virtue of them being part of our service and us seeing the traffic, the patterns and knowledge of attacks across all these different properties on our website, gives them a learning curve of all of the companies combined. The attackers cannot therefore adopt a divide and conquer approach.
How do you handle Load Balancing? All customer web traffic is routed to us today. We enable customers to do three things. First of all, we allow them to perform geo-load balancing. They can go into our dashboard and set up policies so that all their traffic coming from Asia will route to their Asian data center; or the European traffic gets routed to the customer EU datacenter. The next thing that customers can do is global failover. Is a customer has two data centers: one can be active and one can be passive. If one goes down, we will flip traffic over immediately and provide immediate disaster recovery capability.
The last thing we do which is unique is this: In your data center, you typically have multiple servers and a local load balancer, e.g. an F5 BIG-IP. We help customers load balance directly from the cloud instead. We use sophisticated load balancing algorithms, such as least pending requests. We’re balancing the load across your array of servers in the data center directly from the cloud. Having all those capabilities in one single cloud-based traffic controller is highly beneficial.
More and more organizations are deploying a hybrid strategy so they have their legacy applications in a physical data center and they’re also building new environments in the cloud. As far as we’re concerned, we don’t care if you’re hosted in the cloud or if you’re hosted in a physical data center, we provide a single uber-service, which can span across all these infrastructures. You’re using one service across your entire hosting environment.
How do you perform load balancing within in the customer data center when they’re using your CDN platform? Customers can load balance in two different ways, for instance, if each server in your data center has a publicly routable IP address, you would essentially go into that interface set up the IP addresses of these servers. You would then define the load balance policy and algorithm: different mechanisms to determine what’s up and what’s down, just like you’d do with a local load balance appliance. It’s all happening from the cloud so you are not restricted to a single appliance, like an F5. Our entire service is hardware free, so you don’t need anything in your data center.