Our primary use case is to protect our cloud production environment.
We have a co-location that we do with our QA and Dev and our pre-production environment. We do everything there. We built it for the production environment so we deploy everything in the cloud. We have the web application firewall in the cloud, after the proxy.
It has threat intelligence and we are using Incapsula. With threat intelligence, we can separate HTTP and HTTPS traffic. We can use Incapsula to send all the threat intelligence to the WAF.
The interface is very user-friendly. You get used to it. It's very convenient.
There could be some limitations rom the converged infrastructure perspective: when you want to converge with everything and you want Imperva to get there easily, because it's not a cloud component. For example, when you want to build servers and you're using OneView to manage your software-defined networks, implementing Imperva right away is not that simple. But if you're doing just a simple cloud infrastructure with servers in there, you're good to go.
Also, we are not able, with Imperva, to block by signatures. Imperva by itself needs to be complemented with another service to do URL filtering. That's why you need Incapsula.
No issues with stability. It has never crashed.
Scalability is affordable. There are no issues with the process of scaling.
They have centralized management, in terms of scalability. They have centralized policy control, they have centralized application profile information. On the dashboard they have Signature Update, Monitoring, Reporting. They clearly thought about the large-scale when they made this product.
We use a partner here in Puerto Rico for Imperva. We have a guy in our shop every day, full-time.
We used Fortigate. We switched because it's not a WAF. When you have a WAF, you want that WAF to do all kinds of configurations, to promote the firewall, to work the way you want it. Imperva came with everything, the whole package.
The initial setup was a little bit complex. But a third-party took care of everything. It's not like putting milk on cereal when you are working with these kinds of configurations. The effectiveness of a web application is going to come from the analysis of what your organization needs. If you don't have that information before you go into Imperva, you're going to have a lot to do when you get there. You need to know what you're doing. It's not something you can take out of the box and put in your infrastructure. It's somewhat hardcore to deal with these kinds of solutions.
Make sure you understand the way that Imperva charges. It's very affordable. However, I would like to see a package with the Virtual Patching included. You get to do patching separately.
We had F5, Akamai, Fortinet, Barracuda. We may have looked at Juniper as well, I don't remember. Not too many companies have a WAF. Not all the firewall companies are WAF makers.
I think it's perfect. It's a very good application. When you do large-scale deployment you want to protect your physical web application with Imperva, trust me. It gives me peace of mind.
These are guys are from Israel and you should see that place. These guys are the best I have ever seen. They do all kinds of stuff and there is nothing that they cannot do. These people are incredible. They can configure and develop anything, customized, if you want it. Everything has a price, but they can do it right now. They don't have a "no."
We use Imperva with Incapsula so we have web security, we have DDoS protection, we have content delivery networking, we have load-balancing. We do everything with Incapsula cloud. For example, if you have an internet threat, that threat is trying to access your web application. Depending on the threat that you are receiving, the activity monitor is going to be triggered. Once that activity monitor gets triggered, the vulnerability management is going to defend you. It doesn't work for everything the same way. It's very intelligent.
Without tuning, it blocked 88 percent of the vulnerabilities, and when we tuned it, it blocked 98 percent. Whatever was not blocked didn't harm us. We use a third-party for tuning. We tell them what to do it and they do it. They get it done fast, sometimes in two to three days. It depends on what you're asking for. If you're asking for more accuracy, they go the distance to solve your problem. For example, the other day I had some keywords, some attack signatures that they were looking at for false-positives and false negatives, which are two different things. One of the main reasons we got Imperva is that we wanted to block attacks while limiting the number of false positives. I wanted the application scanner not to generate false positives by creating violations. I gave them the information, and the next day it was solved.
To put it in a high-level perspective, you are paying to see the things that are important, but you get a lot of noise. I wanted to reduce that noise. They allowed me to do that.
Make sure you have the right testing methodology for Virtual Patching. If you want to take your patching to under 30 days, this is the product for you. We reduced it to five days. I think we are the only company where the patching is under five days. We are only doing it at the database-level right now. But we took it down to five days.
There are proper ways to test a WAF, but the main advice I can give you is that you should not just generate attack traffic. The most effective method, for me, would be to generate both attack and legitimate traffic. That kind of approach will give you a way to rate the ability of the WAF to detect malicious traffic and to distinguish malicious traffic from good traffic. Provide real-world testing scenarios, in which the WAF must block attacks and avoid blocking good traffic at the same time. You will be able to measure how many false positives you're getting. That is the best way to test a WAF: Don't only to generate attack traffic.
Another piece of advice, and here I will jump to the main fears of this environment - SQL injections, cross-site scripting, which I hate, DT's (Directory Traversals) - is that you need to provide another layer here which is IPS. IPS products will all rely on signatures. They are going to be created by the scanner to stop anything, that's just the basics of threat prevention. If these signatures are easy to circumvent, by using comments and encoding at the same time, they will be available for the WAF to stop any kind of session or cookie tampering. What I'm saying is that there should be technical attack protection. You should be thinking not only about WAF but combining WAF and IPS.
You need to find an IPS that works with it. Imperva has something similar to an IPS, it's not an IPS per se. For example, an IPS cannot detect or stop fraud malware. For that, you need to add certain other levels of security and combine it with employee training. If you get the web application, which is called SecureSphere, the WAF, it will protect you against web page fraud because they go by black IPs. So you can help the IPS on that side and the IPS can help you letting you know what to block from the internal network. You should be considering a combination of WAF and IPS.
Another thing to take into consideration for people who are starting, with respect to deploying a WAF, is that they should validate the accuracy of the solution and the ability it has to protect any application and help you with monitoring and management. It's not just technical stuff.
