ShieldX Review

The insertion of applications in the cloud dropped from an average of three to four weeks to a couple of days


What is our primary use case?

ShieldX has been designed from the very beginning to work well in cloud environments. It understands autoscaling, automation, and auto-configuration. These are the things which are important in today's operating environment.

We have already added it to the enterprise environment. We are in the process now of putting it into production. We are somewhere around 15 to 20 percent done. Our goal is to get up as high as 100 percent within the next six to nine months.

How has it helped my organization?

In addition to our general costs going down, the cost security infrastructure in the cloud has gone down for us. 

We are starting the process of inspecting traffic in the cloud in areas that we weren't able to look at before with our prior vendors. This is something we typically refer to as east-west traffic. 

One of the challenges we have had with other vendors in the cloud is, because of the infrastructure, we were dependent and reliant on the infrastructure that the cloud vendors gave us. We couldn't insert a piece of hardware into the environment. This means that our security layer was going to be applied with the same resources that other instances and servers were running on.

We got into a situation where having a system in the cloud, an instance would generate, for example 10GBs of traffic. With our existing vendor set to apply a security policy east-west, we would need to inspect 10GBs of traffic. Unfortunately, even with their highest-end systems, legacy vendors struggle with inspecting traffic at or near this level of traffic.

What we ended up doing, if we wanted to inspect traffic east-west, was to add layers of firewalls. In a traditional data center, you might have a pair of firewalls for thousands of hosts, but in the cloud, if you are interested in doing an east-west traffic inspection, that ratio of instances to software-based firewalls is much different. You might need to put down a firewall for every five or six systems, which really doesn't scale. There is no way to do it, not from a cost, licensing, or management perspective. It doesn't make sense to do it this way.

This is one of the challenges in applying the older methodology of the legacy firewall technology in the cloud. You can do it, but it doesn't make any sense.

Enter this concept of microservices, protecting only what you need to, so we don't need to absolutely inspect everything going east-west. However, we still need to do it and microservices instrumentation allows us to insert it where we need it the most, so protecting the valuable resources in the cloud and giving us the reach and extension to do the inspection east-west is something we want to do, but only where we absolutely need it. This is something which ShieldX gets that our other vendors don't. This is an area that we are exploring right now and hope to see finalized soon.

What is most valuable?

Legacy vendors were not concerned with the interoperability of their products with our software platforms, like VMware and cloud vendors. They did not design their products from the start to be compatible. Whereas, with ShieldX, this was the beginning of how they began their architecture. From the very first release, they were very concerned with ensuring a lot of these pieces moved together were not add-ons. This is the main core of how the ShieldX product works.

What needs improvement?

It is the things we haven't tested yet. As we go from a centralized data center approach to a hybrid cloud, we are doing this with a single cloud vendor. We haven't had a chance to try this solution in a multi-cloud environment yet. However, this doesn't speak to their lack of integration. This more on us. Over time, we're going to learn about these capabilities in a multi-cloud environment as we expand into other cloud vendors. like Google and Microsoft.

In terms of how we onboard products, when we have a powerful, solid solution, like ShieldX, we want to be able to take its capabilities and the information that it gathers about threats in the environment, then share it with other products that we use elsewhere and have a consistent intelligence sharing platform within our organization. It's about leveraging what we're learning from their product and pushing it down to other products in our environment.

They need to be consistent in performance and capabilities over time, given the fact that this is new and I want to see where this goes in the next year or so. As the vendor continues to evolve and add future functionality, we want to make sure that we are still keeping up with the integrations, etc. Time will be the key factor here. The proper support for some of the latest technologies, Docker containers, etc. They need to keep up with threat landscape, so we will see how the security get layered. This is what we are going to be keeping an eye on. 

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

We haven't had any stability issues come up within the last six months. We are not expecting any, but we will see how the next year goes.

What do I think about the scalability of the solution?

Scalability is the key here. We feel that scalability is better than what we had with our prior vendor. We're in the process now of scaling this out though the infrastructure. Based on what we've done so far, the migrations looks very solid both in terms of its resource utilization, deployment capabilities, and licensing costs. All of these are very positive, and we expect this to continue through our deployment.

Right now, we are protecting about 1000 users with the infrastructure on the enterprise side. We have somewhere around 20 million active users as we are beginning the process of protecting on the customer services side. All of this is being maintained by two to three people. With my prior vendor, we were looking at about eight or more people working with the vendor to protect at the same sort of scale. Basically, we're doing more with less and fewer people.

We have three people working on deployment and maintenance right now. We have a senior designer and two individuals working on the configuration and operations of ShieldX. We also have a ShieldX employee who does our architectural design.

How is customer service and technical support?

With new companies, like ours, support is very good. Our team has been engaged with the same people for all the issues that we have been experiencing. What I want to know from the planners, "How will this scale?" How do we avoid become victims of our own success?

Which solutions did we use previously?

We began our journey into the cloud some time in 2014. At that time, one of our primary concerns was getting the same level security infrastructure that we had used in our own facilities out onto the cloud. In other words, we didn't want to make a movement to the cloud, then be worried about exposure.

We start to spend a lot of time with our existing firewall vendors, the ones that we had come to love and deployed in our data center, talking about what that might look like in the cloud. It took a couple of years for us to get comfortable with a proper insertion point for our existing vendors in the cloud. That meant that we were spending quite a bit of time both in the provisioning and installation phase, but also in terms of our resources. E.g., how much we were spending to get our existing vendor set up and running.

Almost our entire development team within our organization has quite a large number of developers. We moved from the waterfall method where we were doing maybe two or three software releases a year to a more agile environment, where we might be doing a release every two weeks. These people work at a very different pace than what our developers in the past were working at, which also means that the security teams and the infrastructure has to be built up and designed in a way which is more compatible with the way that we are now doing deployments in terms of how we are scaling up on the cloud. It has become very clear that our old way of doing things wouldn't work for us.

For these reasons, our organization was never really designed with the cloud in mind. It felt like putting a square peg in a round hole. For the amount of time that we were spending getting provisioned and the amount of money that we were spending into the infrastructure, everything was way out of line for what we needed to do. It started to feel a like the security teams were getting in the way of the business. This had to change. This is when we started to engage ShieldX.

Here are the primary reasons that we switched:

  1. They weren't designed for the modern hybrid cloud infrastructure. 
  2. The licensing and costs were out of whack for what we were looking to do. 
  3. They were part of an environment that we couldn't protect because of the way that it was originally designed. We are now able to protect it with ShieldX.

How was the initial setup?

It took the team one or two weeks to familiarize themselves with the new way of thinking. It's a shift in the way you apply security policies in the cloud. Once they got used to it, they saw the light and it made more sense to do. There is a bit of a learning curve in the beginning. We had to do quite a bit of lab testing to get the team engaged and ready. Overall, the gains that we see now are well worth the investment.

We spent a couple of months in the lab learning to kick tires and provisioning things in non-production. Our next deployment was on the enterprise network, which was not the revenue generating side of the network yet. That deployment took about a week and a half or so for the first deployment. Now, deployments are happening in a matter of days. This has a lot to do with the team coming on board in terms of how things are working.

What about the implementation team?

We worked with ShieldX, who is very engaged with their customers. We had good responses and spent quite a lot of time with them.

What was our ROI?

When you bring in a new vendor, typically you bring them in together with your existing vendor, so there's a bit of a cost bump. Then, as you start to relinquish licensing of your old vendors, not renewing them, those prices drop. We are actually expecting our costs to drop in the coming year, but it is just a matter of the licensing expiring. That is going to happen in the next six months or so. Then, we will start to see a decrease in overall spend.

Previously, it might have taken us three to four weeks to provision VPCs and environments in the cloud. Very often, we would end up missing certain security groups because we were applying policy in multiple places. Applications wouldn't work right off the bat, so there was a lot of troubleshooting that would come with that, which was part of the reason why it was taking three to four weeks to get things done. Today, all this is thought of ahead of time. Security policies are now applied as applications are going up. Because it's automated, we don't have the three to four week delay. The insertion of applications in the cloud for us dropped from an average of three to four weeks to a couple of days.

What's my experience with pricing, setup cost, and licensing?

We are very happy with the pricing and licensing. It's about getting a site-wide license. One of the challenges that we've had with our previous vendor had been the cost of licensing.

In the beginning, software licensing seemed quite affordable with our prior vendor, as compared to the hardware pricing. What ended up happening was, as we moved into the cloud, we started to create a virtual private cloud environment for every application and sometimes several of them for every region for reliability and resiliency. We ended up with far more VPCs than we had originally thought that we would have. This would have required us to  purchase licenses for each of those from our old vendor. The price would have just skyrocketed.

We were able to solve this with ShieldX to ensure that we can have the separation needed for our environment to avoid drastically increasing the cost on the licensing side. From this perspective, it's been very positive and helpful.

Which other solutions did I evaluate?

We looked at other vendors. We look at our existing vendors, how they are shaping up in the cloud, and the advances they have made. 

We looked at ShieldX and another competitor. It's typically going to be the incumbent plus one or two new challengers.

What other advice do I have?

Take a serious look at what you are spending today and cost model out what you might be spending in a ShieldX environment. You will see that it's very favorable. 

Very often, when new challengers come in, what they do is they end up coming in at a lower cost with more functionality. If you play it right, you can actually achieve more than one goal at the same time. That's better functionality with more rapid deployment and at a lower cost point. That's something which is important and very exciting.

The Adaptive Intention Engine is important. The Adaptive Intention Engine explains what is the reason that we're doing this security infrastructure, what are we trying to get out of it, and what's the intent behind it? The problem with the way that things are done traditionally is you have an intent, but you now have to apply that intent in many places in order to achieve your goals. So, you end up with a duplication of effort in several areas. This is something which could take up quite a bit of time, both from an engineering, operations, maintenance, and troubleshooting perspective. If you have an issue now, you will need to look in two or three places to try and find the source of the issue. There was a lot of tracing which had to happen in our legacy operating method. In the new method, there is one place to design and apply a policy, which is simpler.

It is important to work with a vendor who started their life in the cloud. Cloud vendors are pouring in a ton of money into R&D to the tune of up to $20 billion a year. They are adding a lot of features and capabilities that developers and operating staff want to leverage. Sometimes, three to five new features are appearing from cloud vendors every day. If you can imagine, it's like working in an operating environment where the chessboard is changing on you on a daily basis. It's not like the data center where you're used to working with a certain infrastructure in a certain way. As you built it, the cloud is constantly changing. 

This is one of the challenges that security groups have: Maintaining consistency and keeping up with the rapid state of change which is going on in the cloud. As new features come on board, it's important that those features and capabilities get integrated with the firewall and the way that the policies can be applied evenly. The cloud changes so quickly and it is one of the main reasons that a lot of companies are finding themselves exposed in areas that they may not realize. This is why a cloud-based security vendor is important because they understand these changes. When there is a new feature or functionality that might expose you in a certain way, they make sure the integration applies evenly. This is important for us and the industry.

Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Add a Comment
Guest
Sign Up with Email