What needs improvement with Arbor DDoS?

The technical support engineers can create more labs within the environment. Real-case scenarios that have taken too long to resolve or were escalated can be directly converted into articles. It is highly possible that someone else may also face similar problems. Such articles will help people easily find a solution to their specific issues.

My company is okay with Arbor DDoS. I don't know how improvements can be made in the technology used by Arbor DDoS. I can see that Arbor DDoS is the best in the market when it comes to DDoS protection, as they have very rich features while offering seamless integration between on-prem solutions and its cloud scrubbing centers. My company likes the support offered by Arbor DDoS. My company also likes the scalability capacity offered by Arbor DDoS. When you use Arbor DDoS, sometimes you may face some integration issues with other technologies or other vendors' technologies, which is normal to an extent when it comes to the competition between vendors as they lock the integration capabilities of their products. With Arbor DDoS, its integration issues with other technologies or other vendors' technologies is an area of concern that could be improved. I operate more on the commercial side of the business as I am a product manager in my organization. When speaking about technology from a technical perspective, I am not the right person to comment on what additional features are required in Arbor DDoS. It would be great if Arbor DDoS could enhance its technology and protect users from DDoS attacks without installing any on-prem or customer-premise equipment, but from a technical perspective, I don't know if something like this can be done or not.

The product could have end-to-end platform visibility, including connectivity and bandwidth, similar to Cisco.

The support got worse after NETSCOUT acquired Arbor.

It is an expensive product, so there is room for improvement in terms of pricing.

The solution's IT support needs improvement. So, since we don't have any direct relationship with Arbor, our service provider provides us with the support. Support is an area which needs improvement.

Licensing costs could be reduced.

Arbor's SSL decryption is confusing and needs external cards to be installed in the devices. This is not the best solution from an architectural point of view for protecting HTTPS and every other protocol that is SSL encrypted. Their mitigation rate could be higher. No matter how good Arbor is in DDoS protection, they do not get a 100% mitigation rate. Arbor has the longest tradition in DDoS protection. They have way more expertise in DDoS than anyone else. However, the price of support and licensing is a bit high. They are not affordable but they do their job perfectly.

A behavioral traffic analyzer and SSL inspection tool need to be added. The solution needs to enhance its features to compete with other tools. Lately, Arbor has made some improvements but they are not ones that are expected or ones that would better align the solution with competitors. For example, the solution announced it was releasing SSL inspection in 2020. After a while, they realized the feature was failing so they stopped mentioning it and instead provided another solution which required purchase of a different box. This created a complex topology that is not cost efficient. I have to set aside extra budget so this is not an improvement or a solution for me. Competitors handle the same feature within their own single box.

The solution could be more granular to include logs per second and enhanced pipeline monitoring for router licenses. We would like the solution to offer secure, bug-free portals that could be installed in our data center and be accessible to our customers. Portals built on their own are expensive and time consuming because they have to be aligned with the solution's operational systems. New versions are sometimes released before the bugs are worked out.

Arbor DDoS could improve out-of-the-box reporting, it could be better.

An improvement would be to provide information on how pricing is done on different customer levels (e.g. is it done per gig or bandwidth?)

They should improve the reporting section and make it a little bit more detailed. I would like to have much better and more detailed reports.

On the application layer, they could have a better distributed traffic flow. They could improve that a bit. For network data it is very effective, but the application layer can be improved. In today's era, attackers are also developing their skills. Daily, new threats are coming into the environment.

There is always room for improvement for any product or service. If we can bring in more agility when deploying services, that is definitely a scope which we can work towards. Nowadays, everything is being offered as a service model. It is not that we have to deploy the physical hardware, many things move up to the cloud, or even can be delivered as a VNF in the customer's environment as well. So, in that space, if we can add more features to make it more seamless for customers to use and make it available through some marketplace, not only at the hyperscalers, but also for any on-prem deployment, that definitely would be a big plus. If we could decouple the hardware and software, making it more easily available for the customers with the exact robustness of the functionality, then that would be beneficial. At the same time, it would bring in cost efficiencies, which eventually is the end goal of most CXOs within an organization.

When it comes to some false positives, we need to tweak the system from time to time. There is room for improvement when it comes to the actual mitigation because of some false positives.

I think Arbor DDoS should be more open to other systems, in the sense of coordination between mitigation centers, like for example the capacity to ask the upstream transit provider for mitigation. Netscout's Arbor allows it, but between Arbor systems only. It should be more open to Third party systems, that's what I mean by "openness" : evolution from Netscout signaling protocol to standardized DOTS protocol (DDOS Open Threat Signaling) Implementation could also be improved regarding distribution of mitigation directly on network elements.

We would like the ability to decrypt APS traffic. We need a SaaS model for the solution. I opened a ticket with Arbor for the ability to localize numbers of our customers in BGP sessions. This has not been resolved.

I haven't found anything to complain about or anything that they need to improve on.

Their RESTful API is still a work-in-progress. They're pushing out different versions of the API with each code upgrade. I would also like more visibility into their bad actor feeds, their fingerprint feeds. We try to be good stewards of the internet, so if there are attacks, or bad actors within our networks, if there were an easier way for us to find them, we could stop them from doing their malicious activity, and at the same time save money.

The upgrade process is mildly complex requiring treatment of the custom embedded OS separately from the application. The correlation of the underlying OS to the application version can be easily missed. Linking the white list designation on managed objects into the alert detection mechanism would be a welcome improvement. Currently, white lists to prevent dropping any traffic on important resources only apply to the mitigation process. If the white list could be used during alert detection this would prevent some false positive alerts that are coming from these known good sources.

I struggle with where the product could improve because it's pretty great the way it is. I would just say more granular reporting, down to our customer level, would be helpful. If we could somehow import customer information in their networks, it would be able to generate reports. It might actually be able to do that right now, and we have just never used it. I've dealt with other solutions where I said, "I wish it did this," but it didn't. We have tried some other solutions that do what Arbor does and I would often go back to them and say, "Well, I want it to do this," because we already have that now with the Arbor solution. I've dealt with other vendors and I don't see things that they're doing that Arbor doesn't do.

There is definitely room for improvement in third-party intelligence and integrations. I would like to see more threat intelligence and internal traffic monitoring for C & C communications.

On the main page there are alerts that we are unable to clear, even though the issue has been resolved.

Cloud signaling integration with third-party DDoS solution provider. Currently, it supports only its DDoS APS box.

Because we had some routers that were somewhat old, they were not integrated with Arbor. They did not support the NetFlow version that Arbor was running. That was a challenge. We had to upgrade the routers. Some backward-compatibility would be helpful.

Sometimes it blocks legitimate traffic. If a legitimate user is trying to access the server continuously, the product suspects that this is a DoS traffic file. That is a case where it needs to improve. It needs machine-learning. Self-learning would be an improvement.

The following areas need improvement: * Opening and tracking support tickets * Online support resources * Software upgrades/updates and replacement media * Event management guidelines.

For troubleshooting problems, it's not so intuitive. It's not straightforward. This is the core of their kernel, so they need to improve it a little bit. I don't have a specific example, but I don't feel comfortable troubleshooting Arbor issues. You don't have full control of the system. I also work on F5 in which you have access to the kernel, bare-bones Linux, so you can do whatever you want. Maybe this is a security hazard. Someone may miss something with F5, but for me, as troubleshooter, I have full control of everything. On Arbor, you don't have the same type of control. But otherwise, from a user perspective, it's pretty straightforward.

Sometimes the PPM module gives you an error. They improved it, they deployed a patch, and fixed it. Generally, if it gives you an error, you need to power it off and back on again.

If we want to see live traffic, we can see do so. But once an attack that lasts for five minutes is done, the data is no longer there. It would be an improvement if we could see recent traffic in the dashboard. We can check and download live traffic, but a past attack, with all the details, such as why it happened and how to mitigate and prevent such future attacks, would be helpful to see.

I think the diversity of protection is extremely limited. It must be expanded in future upgrades and versions. Plus, hardware stability is a big issue with Arbor. We have frequent outages with the hardware.

Learning period for managed objects are too short; better to have auto-profiling based on learning.

The look and feel of the management console is a little old, excessively simple. If you compare it with other solutions, the look and feel of the console is like you're using technology from five or six years ago. It doesn't show all the technology that is actually behind it. It looks like an older solution, even though it is not. The first impression needs to be more mature. It needs to be something that you would be proud to show someone. If you have a visitor to your SOC and you show him your installation, you need something more impressive. The look and feel of other brands is really nice, while Arbor is really simple. It's a good solution but not as spectacular as others. It's a matter of marketing, not performance.

There is some room for AI to take place.