What needs improvement with Radware Cloud WAF Service?

The area that can improve with Radware Cloud WAF Service is the speed at which they block geo-fencing and IP for P1 cases, which currently takes about an hour. If they could reduce that to ten to 15 minutes, it would be easier for us.

In terms of areas for improvement, the price is somewhat high. More use of tools such as AI and ML is needed. AI-powered DDoS defense tools and behavior DDoS protections are in place. They should also improve visibility, control, and user interface. The dashboard needs improvement as some users find it complex.

In Radware Cloud WAF Service, areas for improvement include behavioral and anomaly detection, where it could be better by reducing false positives. The AI feature can also improve; while the API is fine, behavioral and anomaly detection sometimes learns automatically from the traffic, potentially triggering false alerts.

They can work more on the documentation part. The documentation I found is quite vague. There can be more practical examples, and since we are a paid customer, they can give us arranged training. They can arrange sessions or trainings regarding using Radware Cloud WAF Service and what further things we can do. I recently learned about source blocking, so training or sessions can be organized, along with improving documentation with practical examples.

It's medium to difficult to use the Radware API Discovery due to its complexity. I have almost two and a half years of experience, so I'm familiar with this service, but recently, we have had new engineers rolled into our operations teams, and they are finding it challenging to understand from the start because of this complexity and the different approaches for hardening and best practices to ensure everything runs smoothly. So, for a new user, it's between medium to difficult based on the complexity. The implementation of Radware Cloud WAF Service is complex. However, this complexity is not solely attributed to the Cloud WAF, as we have experienced compatibility issues with different vendor devices that have hindered integration. While we can integrate it, we definitely face challenges if the engineer does not know exactly how to execute it. The command for the integrations and the procedure are somewhat complex, yet it's really helpful overall. We haven't encountered a single device suggesting that Radware is not compatible for integration. We wanted to integrate with some Cisco devices, but due to version gaps, Cisco TAC informed us that those devices are not compatible for integration with Radware.

From a documentation perspective, the documentation needs updating in terms of ease of implementation. Users have to work with it independently once or twice to get accustomed to it. The documentation doesn't contain all necessary information, requiring users to read other forums or seek help from colleagues who have experience with it. Regarding zero-day protection, it takes considerable time to update signatures in the Radware Cloud WAF Service. There is typically a delay of one to two days after a threat has been reported in the wild before signatures are updated and applied to the detection engine. The reporting functionality needs improvement. The dashboard offers limited customization options. They have preset dashboards visible on the main page, but customization options are restricted. For management presentations, users must extract the data and create their own visualizations. The API protection documentation needs to be more thorough to help first-time users configure it easily.

The dashboard of Radware Cloud WAF Service could be more interactive and user-friendly. While implementing it for the first time, it requires core technical knowledge, and without that knowledge, implementation can be quite challenging. However, the support from Radware is excellent when support cases are raised.

The automated analytics for looking at events is where there is room for improvisation in the Radware Cloud WAF Service. They are working on improving the automated capabilities of workflows and integrating AI, but it's not quite up to the mark yet. There's a lot of work to be done since various customers have different requirements, and any implemented automated features should provide expected results. They need to improve the support side. Information should be more readily available on their support portal, especially knowledge-based articles for customers to resolve queries independently. The support portal used to be slow, and the UI experience was less than ideal, although it has improved over time. Additionally, the lack of an AI chatbot has been a downside, though we have been notified that functionality is in development now. On the reporting side, customization options are limited; creating tailored reports is currently not possible, which is a significant drawback since full customization is crucial for effective data presentation.

The log feature in Radware Cloud WAF Service has some limitations. Unfortunately, the portal does not provide much information. If there is an issue, we may need to raise a case with the vendor to obtain further details. Aside from that, the other features are quite good. In the Radware Cloud WAF Service, areas that have room for improvement include the logs part. Currently, we only see logs for requests that are getting blocked. It would be helpful if there was a feature to view all application traffic logs. Also, the visibility on the configured rules in Radware Cloud WAF Service is not better; we do not have any visibility on those rules. The two areas are logs and the visibility of rules, which need improvement.

Improvement areas could be some of the AI capabilities related to false positives. The required IP addresses sometimes get blocked, so that needs to be enhanced. The AI recognizing features can be improved. Recognition aspects could be refined; it's performing at almost 99%, so there's a small margin for improvement.

I've not explored deeply enough to identify areas for improvement in Radware Cloud WAF Service, but I can mention the retention policy. I'm not sure about how much historical traffic data we can access. Knowing the ability to view traffic from six months back would be beneficial for audit and compliance purposes, especially if an attack happens on an application. There was a request in the past that we couldn't fulfill due to this limitation, so I'd like to know more about the retention policy.

Radware Cloud WAF Service could improve its application onboarding process, as it only supports ports 80, 443, and 1024–65535; key ports like 993 and 995 needed for SMTP are unsupported, limiting email app protection. For IP whitelisting, the current setup allows all traffic from a specific allowed(whitelisted) IP without detection, which exposes threat. A more granular approach—allowing both page- and IP-specific access while detecting threats—is recommended. The service earns eight out of ten for reducing false positives, but some legitimate traffic is still blocked due to header parameters. Whitelisting helps, but further improvements and AI-driven behavior analysis could enhance accuracy.

They might need to add more integrations. Adding AI-based search capabilities would be beneficial, allowing us to search for the origins of bot attacks by country. The behavioral analysis could be made more efficient. While Bot Manager has many of these features already, there is room for further enhancement.

Radware Cloud WAF Service has helped reduce false positives, but we do experience some false positives, such as when certain URIs or headers are incorrectly flagged as malicious, and we need Radware to refine those to treat as genuine traffic, achieving about a 25% reduction in false positives. There is an area for improvement in Radware Cloud WAF Service, specifically regarding the visibility of default algorithms or source blocking systems that create false positives, as it would help if customers could see these blocks to isolate problems quickly without needing to reach out for tech support. There are various blocking systems in place, including some default algorithms that can block a lot of content. Unfortunately, this can lead to false positives, making it difficult to determine whether an issue is being caused by Radware WAF or something else. As a customer, we can't see what's happening behind the scenes because it's a SaaS service. I would suggest that if there are any blocks, they should be clearly visible to us. This would allow us to isolate the problem and understand whether it's related to the WAF or another source. Currently, these blockings are not transparent; they remain hidden until we reach out to the tech support teams. Often, we only find out about the issues from them, which leaves us unaware of the problems as they aren't displayed in the portal. These behind-the-scenes elements should be available. I understand it would have read-only access. That's acceptable, but it should be visible so we can isolate issues quickly.

When it comes to support, I would suggest having a dedicated number for our clients for better identification in case of issues, as the varying numbers make it easy to miss important calls. Additionally, alert messages for DDoS attacks or other things take time to reach us, causing delays in our response. I see potential in adding threat intelligence, and I don't have issues with the responsiveness or user-friendliness of the Radware console. It's definitely user-friendly for me.

I see areas in Radware Cloud WAF Service for improvement, specifically in its initial tuning period, because the machine learning model takes two to three weeks for baseline behavior establishment. Closely monitoring alerts during this period is essential to avoid false positives. There's an alert noise issue; during the early stages, we received a high volume of alerts for minor issues, requiring collaboration with the SOC team to fine-tune thresholds and concentrate on genuine threats. The documentation is not up to par, as while the platform's system is robust, the documentation, particularly for API integration, could be more developer-friendly with real-world use cases.

Some of the tools are a bit difficult to navigate, and the user interface could be more user-friendly. It is not the cheapest solution, so cost is something to consider.

There should be more customization options for the dashboard, as it is currently fixed and cannot be modified. Additionally, the API is limited to data retrieval and does not support programmatic modifications. It would be beneficial if we could perform POST requests and integrate our applications more effectively.

An area of improvement is the visibility at the attack level. Management often asks for detailed reporting on attacks such as botnet and zero-day attacks, including the number of attacks within a month, week, or day. Improving dashboard capabilities to provide this information clearly for management is crucial. They need to improve their reporting. We need to present our management with reports and we need better options for reporting. They don't want lengthy reports. They need something that is one to two pages and includes everything - a more high-level document with the most important information.

Complexity of Setup and Configuration:

Some users report that setting up Radware Cloud WAF can be somewhat complex, especially for organizations without dedicated security teams.

Customization of Rules and Policies:
While Radware provides security policies, users sometimes find that more granular control over custom rules and policies could be beneficial.

Real-Time Reporting and Analytics:
Reporting features could be more intuitive. In particular, more real-time monitoring and easier-to-interpret analytics could help security teams make faster decisions.

False Positives/Negatives:
Like many WAF solutions, Radware Cloud WAF can sometimes have issues with false positives or false negatives, flagging legitimate traffic or missing malicious activity.

Integration with Other Services:
Expanding compatibility with a broader range of third-party services and APIs could make it easier for organizations to integrate Radware with existing security infrastructure.

API integration and documentation need to be improved. There should be more detailed documentation for API usage, rate limiting, CNAME, and DDoS functions. A lot of articles need to be added to their portal. Additionally, enhancing the capabilities for bypass functions where users can manage URLs more flexibly, including the use of wildcard characters, would be beneficial.

Radware needs to improve the certificate renewal process for customers who want to be secured with HTTPS. Some other web application firewalls have a mechanism that allows automatic certificate uploads, which Radware could adopt. Also, improvements could be made to be more precise on the negative security perspective.

It needs a better reporting and dashboard to provide better insights.

They need to improve their reporting. We need to present our management with reports and we need better options for reporting. They don't want lengthy reports. They need something that is one to two pages and includes everything - a more high-level document with the most important information.

Cloud WAF's management portal lacks many indicators, and the interface could be more user-friendly. It should provide more detailed information on events, possible solutions, and what each event means. While it does give you the event and block part, it doesn't give you a solution. Let's say, for example, someone wants to go into an SQL injection and find a possible solution other than the blocking part, there are no details. It would be good to have possible solutions or the ability to create an automated report to send to the developers in the portal. Also, they should offer more Spanish-language tutorial videos. There is only one tutorial in Spanish, which is difficult for us as Latin American customers.

Radware's bot manager can be improved because it's very complicated to implement for apps. Radware could also add alerts by WhatsApp or Telegram. It only sends notifications via email or SMS.

The Cloud Portal has room for improvement.

We have had difficulties with the configuration of rules when it comes to allowing connections and having a list of IPs that are authorized to use a specific service. We have not been able to make a whitelist work. For example, if we want to publish services to a limited number of providers and we only want those providers to connect, we need to forward those requests to the Radware support team and they apply them, but it takes some time. It seems to me that this long process would be faster if the configuration could exist directly in the portal. That would make things easier.

They have a portal for webinar training but because we are in a Spanish-speaking country, it is difficult for us to watch them. Not all of us are fluent in English, but most of the courses and webinars are in English. That part could be improved, with more options for people for whom English is not their native language.

The reporting has room for improvement. We've had some issues with putting certificates in. We considered using Radware Cloud WAF Service to protect our API gateway with a WAF. However, we encountered issues with licensing since we had to obtain a license for each individual connection, which was not suitable for our API. To deploy one API Gateway, we would need to purchase 30 licenses, which was expensive. Additionally, we experienced difficulties with obtaining support and resolving the issue, which went on for several weeks. Eventually, we decided to explore other options due to the lack of time to address the problem. The scaling is not cost-effective and has room for improvement.

They've changed their process for call logging. I suppose it's fine, but I used to be able to send emails in. They could also build up more local resiliency here in South Africa. They're working on that, so it isn't much of an issue now.

The primary area for improvement is in issue detection and understanding whether a log is a false positive. It can sometimes be a challenge to take the data of a given security event and determine if it's a genuine threat using a Wiki etc. Navigating to find specific options can sometimes be challenging, but we only do this occasionally; we primarily control the logs, so it's not particularly significant for us. We had some issues with the initial implementation, especially around tuning the solution to avoid false positives.

The integration part could be better. The visibility part could improve as well. In the market, everyone is moving towards the cloud. However, the patience is not good. When we are trying to find out some information, we are not getting what we need on time. They need to arrange some more use cases for their partners, for their customers to showcase their product and show exactly how it is working, how they're capturing the market, et cetera. Right now, they aren't showcasing what can be done, making it hard to sell. I've found it difficult to find good documentation for cloud deployments.