DivvyCloud Reviews

We use DivvyCloud to monitor our workloads in Docker and Kubernetes. From a security classification point of view, we use it to ensure that the workloads are protected. This ties into our DLP. We have a DLP policy and then a data classification. 

The data is classified as critical, private, and privileged. We also have policy controls that allow whoever the users are to gain access to these cloud resources. We use that tool to provide the framework and also the governance.

I find the security frameworks and security tools valuable. I think they're good in the infrastructure of the code security. They are also good at threat protection.

Technical support could be better. It could also be easier, more user-friendly, and intuitive. The API keys aren't easy to understand, and the cloud layouts aren't intuitive and user-friendly. We should be able to integrate IM governance and APIs into non-compliant workloads like legacy solutions. 

As far as the interface goes, I would like the look and feel to be a little bit more modern. Sometimes the interface is a little bit cloggy, but that's just my preference. This is because it's different from the other panes of glass we use within Rapid7's portfolio. It's a different view because they acquired that company. Maybe long-term, they are going to integrate that into their other product portfolios.

I've been using DivvyCloud for about four and a half months.

We're happy with the stability of the solution. However, the interface is sometimes slow because it's a SaaS application or a cloud service that's a little bit slow at times. 

We feel like it's going to be able to scale according to our needs. We have about 15 developers using it right now.

I'm not impressed with their support right now. Their support model is not really good. They have a portal or forum, and we did have some dialogue with them on the initial setup.

The initial installation was a little difficult, but we're using that as a template. However, prior to deploying that tool, we ensured that all of our workloads followed a standard framework for building out those containers and those workloads in the cloud. 

Technical support was able to assist us with this template, but it was a little bit of a challenge initially. However, now we're able to use that and fairly easily retrofit that onto new workloads. It took us less than two months to deploy this solution. But we're still developing the policies that go behind that and should be completed by late September.

We implemented this solution ourselves, but we did have some engagement with Rapid7. We didn't pay for professional services. We just used their technical support. 

It's saved us a little on the back end in Azure costs. 

We're doing an annual subscription. There are additional expenses, but not within the confines of this platform. 

We looked at a couple of other CASB solutions like Proofpoint CASB and Microsoft's CASB solution. We went ahead and selected DivvyCloud because we were already a Rapid7 user and a customer in relation to managing detection and response. 

My goal was to try to limit the number of different tools and keep tools consistently in one framework. That's kind of one of the reasons why we selected DivvyCloud. 

I would advise new users to have all their ducks in a row first. It would be best to have all your governance and framework policies built ahead of time regarding how you will deploy it. I think it's very difficult to deploy a solution without knowing what your internal processes are going to be. That's kind of a mistake that we've made in the past and continue to make.

On a scale from one to ten, I would give DivvyCloud an eight.