Radware offers a cloud, software, and hardware-based solution. It deals with all three platforms.

1. They have a hardware device on which their software can be installed. We can manage all the load balancing with it.

2. Similarly, for the Radware software, we can install the OVA file on our server and configure all the admin backend servers on it to perform services.

3. In the cloud, we can use their API service to create a virtual platform for clients on which they can deploy and run their applications.

Cloud WAF blocks unknown threats and attacks. We have a monitoring tool, and security patches are released monthly. We can deploy these signatures on the WAF, which identifies threats based on IPs. There are multiple signatures for various attacks, like bot attacks, that we can monitor.

There is a forensic dashboard where we can identify real-time events, hits, and blocks. If there are genuine requests being blocked, we can deploy a custom page with a case number for users to resolve issues. For example, if a user triggers the Web Application Firewall (WAF) due to a misinterpreted service, they will see a blocking page with a case number. There's also an option to refine the WAF settings if it blocks a genuine request.

I also work with the API discovery feature in the Cloud solution. Once the API is enabled and the application vendor provides the API key, we can deploy our application. If the API is correct, it functions properly; otherwise, issues are highlighted on the dashboard. For example, cross-site scripting is blocked at the label level.

API discovery is straightforward to use. There is an option to add the API stream. If the API is correct, it will be processed; otherwise, the API service is blocked.

The dashboard provides multiple features and analytics tools to identify API issues. If there is a cost issue with an API, it can be identified, and we can report it.

It's not difficult to work with the API discovery feature because everything is reflected on the forensic dashboard. There's an option within the dashboard, under the security section, where you define the correct API. You can also identify and exclude specific APIs if needed. There's only one option to add to the API stream. If the API is correct, it will be processed; otherwise, it's blocked.

It's not difficult to identify API issues because when we define the API call, and it is incorrect or not valid, it won't sync with the vendor's application. They identify this and generate a blocking request, which helps us easily identify the issue.

It's mostly for the Alteon service. The Alteon load balancing part, particularly the SSL offloading and WAF offloading, is crucial. Offloading allows us to monitor and identify issues easily. I believe the SSL offloading is the most valuable feature.

It's easy to use, and the configurations are similar across different vendors. Compared to F5 and Citrix, Radware is easier to communicate with and use. The configuration process is simple, involving the creation of groups and pools, much like in F5. The SSL offloading is also very easy. Overall, I think it's a good solution.

The service we use through the cloud is very easy. We have one dashboard to manage everything, which is convenient.

The analytic dashboard could be integrated with other platforms like Splunk. In Splunk, the dashboard shows multiple things, and I think Radware could improve its dashboard in that regard.

In the WAF part, there are multiple things that are initiated, such as updates and patches. There's a global issue right now that we need to monitor on our side. I think the ability to monitor server-level updates and patches should be integrated into the WAF.

I have been using it for three to four years.

If we raise an issue, they usually identify and resolve it by the end of the day or the next day. There haven't been any escalated cases on the cloud. However, we did encounter one issue regarding the filter and signature. We created a policy to block access from Pakistan, Bangladesh, and other specific locations.

Although the policy was in place and checked, users from those locations were still able to access the application. This was a bug that we reported to the technical team. They identified an issue with their software version and provided us with a new version to update. After the update, the blocking feature worked correctly.

It's scalable. We can customize it as per our requirements. We can customize it in most cases.

In the State Bank of India project, we deployed it, and I believe two or three other banks are using Radware's WAF. Some applications are deployed globally, meaning they're used in Australia, America, and multiple countries. We have multiple deployment options for that. For example, the YONO application is deployed globally and used by many users in different countries. We can easily identify and track that traffic on the dashboard.

In addition, they have also deployed the DDoS service in WAF. So, in case of a DDoS attack or something similar, they can easily identify and monitor it.

It's software-only, so most of the time it works as intended. However, I did raise one request about a filter option in the dashboard not working perfectly. We identified that there was a version issue, and they fixed it in a new patch. They were able to easily identify and resolve the version issue.

They are not globally available but can manage and support us within a range of five to seven. They can usually provide support easily.

I have worked on Citrix as well. Both Citrix and Radware are similar, but in Citrix, some things are more lengthy. Radware is better integrated and easier to understand, so anyone can use it.

I haven't directly compared them, but F5 is very popular globally. Both are similar, but Radware lags behind F5 in a few features.

In terms of user experience and management, Radware is easier. However, F5 has better performance.

Both are cost-effective, but Radware is less expensive because F5 licenses are costly. Technically, Radware is easier to understand.

We currently use the integrated WAF option on the same device in our application (SBI). There is no dedicated WAF solution. There are two options: license-based and integrated. Using the integrated part helps to identify blocks and other issues effectively.

Integrating with other systems and applications in the environment:

Integration is not difficult. In the dashboard, under the policy section, we can find virtual services and easily enable the API service. Once enabled, WAF monitoring should also be enabled. We can then identify the application's requirements, like JSON ID, cookies, headers, what should be whitelisted, body size, etc.

We can gather this information from the application owner during deployment to determine what needs to be whitelisted, such as extensions, zip files, XML files, and cookies.

Once we deploy an application, it doesn't take too much time because the application is already deployed. We also use the load balancing feature, so we just need to enable the security web application service. There is an option for this under virtual services where we can also enable it for bot protection. I think anyone can easily manage it if they know about these things.

Radware is signature-based. The patches and signatures are important because we cannot easily monitor them ourselves. They are regularly updated, I think, weekly, so that's helpful. I think this regular update makes it easier for us.

We are a managed service provider (MSP) for Radware. The technical support is handled directly by Radware, but we manage the technical aspects.

We use integrated and cloud solutions because we manage multiple applications for multiple vendors. Some vendors are using the integrated WAF, which is good. The cloud part is also managed by us, not the customer. We deploy everything, including signatures and patches, if needed.

We can deploy it within a month. It's very easy to deploy and work with. If you create load balancing and WAF configurations, both are very simple. The deployment process is easy if you know how to configure it. Anyone who knows the basics of networking and security can easily deploy it. The dashboard and management are also simple. There is no confusion.

If you're creating a virtual service, you can easily create the virtual service port and configure the backend server. It's very simple.

In F5, when creating a group, you need to take one pool service. But in Radware, you can create one group and easily select it. The dashboard and configuration in Radware are very simple.

We mostly deploy in one-arm mode, but there's also a two-arm mode. In one-arm mode, all applications and servers are on the same subnet. We take a single IP from the subnet (e.g., 10.86.11.x). We need three IPs: one for management and two for deployment and virtual services.

When deploying an application, we can use the same IP range. We deploy all backend servers on the virtual service. We select the backend servers and multiple ports based on the requirements. We then configure the services on the virtual service and review everything. For networking, we need to do NATing if the application is globally accessible, which is also very simple.

The dashboard and conciliation aspects are straightforward in Radware.

Just as in the same domain, we can deploy mainly in one-arm mode, or two-arm mode. There are two different modes. Okay? But typically, we deploy in one-arm mode. In this mode, all applications and services should be on the same subnet. We can take a single IP from the same subnet, for example, if you have a subnet of twenty-three, like 10.86.11.something. We require three IPs in total. One IP for management, and two others for deployment and the virtual service. If we deploy an application, we can use that same IP range. We take it. And on this virtual service, we can deploy to all back-end servers. We can select the back-end server and multiple ports based on the requirements. We can select the ports we need and configure the services on them. On the virtual service, we can configure all the services and review everything. For networking, we need a NATing part if the application is globally accessible so we can NAT through their public IP. It's a very simple deployment process.

For a new project, it might take longer than a month due to approvals and networking configurations. These processes, especially to get approvals for NATing and network paths, can be take time. That's why it takes almost two months. However, if everything is ready, deployment and testing can be completed within five to ten days.

Two resources are enough for the deployment. From a maintenance perspective, not much is needed.

It does bring ROI.

Radware is less expensive because F5 licenses are costly. F5 charges for each and every license. For every virtual service you create, you need to pay additional license fees. The licenses are more COSTLY compared to Radware.

Radware also has lower annual maintenance costs (AMC) compared to F5. F5 is more expensive than Radware, but it's the leading product globally.

It's not very costly because everything is license-based, all things depend on the license and annual maintenance contract (AMC). If you have an AMC, the cost will be higher. Without an AMC, the cost is less because the product itself is less expensive. But if you have the AMC, the cost will be higher.

If companies provide the signatures and patches perfectly because we can't easily identify new viruses or threats, we rely on the solution company to regularly update their software and devices. Radware is one such company that updates its patches and signatures monthly. They allow us to review all the CVEs and update their patches accordingly. So, I think it's a good option.

Overall, I would rate it a seven out of ten because there are some issues in the cloud part, where it lags.