ShieldX Reviews

Our primary use case is protection of our website. About 70 percent of our holiday bookings, about 7,000 in total, go through our website. ShieldX protects that environment. When we moved from a physical environment in Rackspace — and this was a project that we started two and a half years ago — we identified the main risk to the business, which was infection of the website. We were moving our site to AWS, from a hosted, private environment to a private AWS environment. We were concerned about the potential damage to the business if we got hacked. ShieldX was a necessity to enable us to move the business forward into AWS.

We have two installations of ShieldX. We have one installation running in AWS, it's protecting our web environment. And we have another installation on-prem which is protecting corporate servers.

The solution makes the cloud safer than an on-prem deployment because of its proactive monitoring and blocking.

One of the best time savings the solution provides is because of its antiviral nature. By deploying it on-prem, we have not had any infections on our servers since we started running it in-line. That eases workload.

We haven't had any false positives. We haven't had to blacklist or whitelist anything. The system as a whole is fairly self-contained.

We run an automated penetration testing tool and we try to get into the website and into our servers with the pen-testing tool. We couldn't get into them. We could see the attempts on the ShieldX logs, but the pen-testing tool just couldn't get through. We've got the comfort that it picks up the testing tool. We know the testing tool is working when ShieldX is working.

The most valuable feature is the automatic scaling. With its microservices, it scales both up and down, depending on traffic and throughput. The traffic through our website depends on holiday bookings. It's very quiet in November through January, and then our traffic picks up quite rapidly and, at our peak, we will take in excess of a million pounds of business a day through our website.

The UI was also one of the huge selling points. My web development manager was blown away with the detail and the granularity that you can get out of the UI. It is a very strong and informative UI, with the amount of data it provides. 

Uptime on the system has been 648 days and we do very little to it because it self-updates and alerts. It does everything that we need it to do, so the administration side of it is zero. One of the beauties about ShieldX is that it's such a good "fire-and-forget" product.

I haven't any problems with it whatsoever. It's been solid.

The scalability is fine. One of the concerns in running in AWS — and AWS costs you — is that you don't have any control. As long as you keep an eye on the AWS costs for that ShieldX server, you don't get any fits from AWS costs.

As threats evolve and ShieldX evolves with it, it's like you've got a forever-evolving beast and the solution is evolving to meet the threats. It updates itself automatically to tackle those threats, which is why it's such an easy and lightweight product to manage. It really does everything for itself.

The times where we used tech support to run through the installation, the setup, the testing, they were first-rate. They really know the product well.

We've contacted them with some "how-to-use" issues or "how-to-view" and how to get reports out of it, but it's an easy-to-use product.

In terms of documentation, we were a very early adopter of ShieldX and we were guided by them.

The one criticism I might have is there should be a bit more customer care, with regular review meetings on it or regular reports. It would be nice to have a quarterly or biannual review of what ShieldX has blocked. Maybe we don't have that because we go through a third-party vendor and maybe they should do it, but one way or the other, it would be helpful.

We used a product called Alert Logic. That was the product that Rackspace wanted us to purchase. I think there are different incarnations of the product now, but because that product was reactive — it was analyzing the logs — this was the thing that we were concerned about. By the time an issue occurred, if 15, 20, or 30 minutes had passed, that could end up being a lot of data that's been taken out of the system. For us, it was a non-starter. ShieldX with its proactive nature was a lot better.

The biggest selling point — and we were being offered various monitoring systems to monitor our website for intrusion detection and alerting, and albeit they were very good — was that ShieldX, at the time, was the only product that would proactively monitor, block, and then report that it had blocked things. It then had the ability to allow that traffic or leave it as denied. For us it was a no-brainer because somebody could suck all the information out of our website within a matter of an hour. Whereas ShieldX, if it detects that sort of intrusion, would lock it down and shut it down instantly.

Our concern was that if somebody is reactively monitoring and they detect an event, there is a 15-minute or 30-minute SLA on it. They then report it to us. If it's 2:00 in the morning and the infection continues until 7:00 in the morning, when we pick up the message, and it then gets locked down, by that time all our data and customer information would have been sucked out of the website. That was one of the main factors for moving to AWS: We had to have some form of proactive blocking and monitoring, intrusion detection, on the website.

For us, Alert Logic was an old-tech product and ShieldX was an up-to-date, new-tech, modern product. When you talk about having a call center monitor stuff on your behalf, there is always going to be inherent delay between an attack occurring, detection, and then notification. The more you can reduce that window when an attack occurs, then the less susceptible you are and the less risk there is to the business. That was one of the main reasons we didn't like Alert Logic. With ShieldX, that window completely closed.

The initial setup was really straightforward. It took about two hours of ShieldX's time for the install. It took about four hours in total. At that point it was fully integrated into our system.

We had a few conference calls beforehand, to discuss the environment. We exchanged environment maps. But the injection of ShieldX into the AWS environment was very straightforward. It sits in-line. All network traffic flows in and out of it. It was a case of having the box set up and then the ports changed to route traffic directly through it.

In terms of implementation strategy, we were in quite an easy position because our existing web environment was sitting and running on a physical Rackspace server. We had a brand-new website sitting on AWS and ready to go. We actually had the time and the luxury of being able to sit and configure ShieldX and put it into situ. It was two or three months later when we did the live cut-over to AWS. We installed ShieldX and put it in listen mode so we could see what detections or what potential problems there would be. We quite quickly switched it to full protection mode because it became apparent that it wasn't going to cause us any problems. And it hasn't. It hasn't caused us any problems, it hasn't caused any performance issues. The throughput is fine.

It took one main engineer from ShieldX. And we used the UK reseller, a company called Cloud Digital.

Cloud Digital was really good. We put any issues or any questions to Cloud Digital and they resolved them with ShieldX for us. It was fairly easy. The original proof of concept and testing that we did were very impressive. We staged up little virtual machines within our environment which attempted to hack or flood the servers. We could actually watch as ShieldX picked up the attack and within less than a second blocked the attack. We simulated a DDoS attack and ShieldX blocked it almost instantly. There were very various things they did to prove how well the product works.

The most recent issue that we had had to contact Could Digital for had to do with an upgrade in the environment. That one came in the other way. It was ShieldX that contacted us because they needed to update ShieldX. Other than that — and I'm looking at the dashboard now — it's been fine. I'm looking at the throughput and various events that have been touching the website and I can't fault it.

ROI is not something that you can really quantify on a security product. Look at some of the companies that have been hacked. It'd be very difficult to justify that. 

We did quite a good deal on ShieldX. For a three-year deal we paid £55,000 plus tax. That works out to about £1,500 a month. Alert Logic was £2,500 a month on a three-year deal.

But, and this is a big "but," this was over two years ago. ShieldX had only just hit the market. We were the first company in Europe to buy ShieldX. I think one other company became the first customer worldwide, just before us. So ShieldX was very keen to get a customer base.

I would tell other security professionals who are looking to justify the budget for ShieldX that once you install it you can virtually forget about it. It's very low-maintenance and high-protection. There are products out there that you need to tweak and monitor and check. With ShieldX you simply don't have to do anything. You put it in, fire it up, and then you forget about it because it's sitting there in the background, monitoring. It will alert you if something occurs. It's that good.

I don't think there's anything in the solution that really needs improving. It does everything that we need it to do. It depends on how you're going to deploy it, or what the endgame is. Our endgame was to be able to sleep at night because we knew that the website is proactively protected. It's done exactly what we wanted.

Internally, for our file servers that we're protecting, we have around 550 users going through one environment. On the website, we will peak at taking 500 holiday bookings a day. So the website's not huge. It's not an Amazon or a YouTube. We're talking about 50 to 100 connections at one time.

We're happy that ShieldX is protecting us. ShieldX is a great product. We wouldn't have moved into AWS without it, because of the protection that it gives. It's definitely well worth it.

The primary use case is microsegmentation. We are segmenting our servers, so only people who need access to a server can see and access it, then vice versa. 

We are using the latest version and deployed around September/October last year.

1. We were able to see what devices are talking to each other, giving us more visibility.
2. It has helped us tighten our security posture. Now, staff can only access things that they should be accessing. Before, users were able to see every server out there. Not necessarily meaning they could access them, but they could see them. Now, with microsegmentation using ShieldX, we have been able to tighten this down.

• It is good for its cost.
• It is very easy to use. 
• It is very easy to scale.
• It is easy to implement and doesn't take long.
• They have a good support team with training and videos on different things.

I create CIDR groups or workload names for either IPs or servers. In the CIDR groups, I have either multiple IP addresses or I am just doing it by the IP range. If I create a CIDR group type, then I tie an ACL control to what devices I want. This is where I am spending most of my time, creating these groups and tying them down to where they only talks to certain servers. I am also finding out that there are more things talking to each other than I originally thought, which is good. I thought one server was only speaking to these set of IPs, but they are actually talking to quite a bit of IPs.

What I like about it now is that it has a single pane of glass to view our networks and groups. Also, in Vmware, it creates its own distributed switches instead of using my current VLAN distributed switches.

Since we are just rolling it out i cant really say much of what needs to be improved or not at this time. However, I do know that they have made improvements since we have first rolled out the product which has been great. One of the improvements has been its own distributed switch creation group where now all VLANs that is micro-segmented are in instead of having it in your DS/standard switch groups.

We are having some issues with their LDAP and integrating it with the Active Directory. We can't seem to set it up. I have been working with the ShieldX technical support on this, but I would like a better way to set this up. When I put in any credentials, it fails. This is possibly due to how our tiering is set up for our protective groups. However, we tried to do this process through the API and still received the same error.

I don't feel like I am using the product to its fullest extent.

I think one feature that I would like to see in the near future is having the application integrate with a SAML identity provider like Okta. 

The stability has been good. I don't have any problems with stability.

Once the product is up and running, it only takes one person to maintain (me).

The scalability seems good, so far. I haven't rolled it out that much, but I don't think it should be that difficult. Everything seems like it is scalable to what I need, though we haven't rolled it out to that many servers yet. I don't see it being a problem.

We plan to do more soon. We want to implement this 100 percent in our environment, which is not large. Right now, we are at 50 percent. This will probably be done in the next two months, before summer.

My boss and I are the two people in the organization who are using the solution.

ShieldX's technical support has been great. I put in a ticket or send an email, and they are very responsive. It is not just their tech support. I can call one of their directors, if needed, who helped me through the install. So, I think their support has been great so far. I haven't had a problem. 

They are pretty knowledgeable. They can definitely figure things out. If not, they know who to reach.

Before ShieldX, we didn't have much of a security posture. We were trying to get there. We tried Illumio and bought the product, but it just seemed very difficult at the time. The person who took over that project left, then I came in, and I was trying to catch up on the products that he had left over. By the time, we looked at Illumio and their dashboard, learning their product seemed more time consuming than we wanted it to be. So, we decided to transition to ShieldX.

The deployment took time, but it was more on our end. We were trying to figure out what we want to accomplish when we microsegmented it. We were making up some rules, but did not realize that the product was talking to more servers than we realized. So, we had to stop with pauses in-between and figure it out, because now when we put it into microsegmentation, people couldn't get to the SQL Servers and jobs started failing. While this all took a few months, this has all been squared away.

The initial deployment was straightforward. It was more of an eye opening for me to figure out. For example, I forgot to add our multifactor server to allow the SQL Servers. When I didn't allow it, nothing worked. Then, when I took it out of the microsegmentation, it worked, and I got to figure out what rules and IPs that I needed. 

Once everything is installed on my vCenter in Vmware. This is how my setup is set up, which I feel is safe.

We did the implementation with the ShieldX team. I was the only staff required for the deployment.

For the implementation strategy, we needed to figure first what talks to what. We started with the most important servers, then continue on to the rest, one or two servers at a time.

We have been able to secure more things using this product. 

For other security professions who are looking for something which is low in cost that does microsegmentation, they should look at ShieldX. It might not be the big name out there, but it does everything that you are looking for in microsegmentation at a very low price.

We did not try any other solutions beside Illumio. There are two main difference between the products:

1. With Illumio, you have to install an agent on every server, and you don't have to do that with ShieldX, because it is agentless. 
2. The ShieldX GUI that you log into is much easier to move around in than the Illumio user interface.

Both products are pretty low in cost. However, ShieldX gave us a better deal over three years, which played a role in our choice.

Stop looking and try it. Talk to ShieldX and determine if this is what you need in your environment.

While I am familiar with the Adaptive Intention Engine, but I don't really pay much attention to it.

We haven't done any migration to the cloud. Everything is on-premise.

Our primary use case is to provide microsegmentation and microsecurity controls in a multi-cloud and multi-data-center environment.

The primary driver, as far as how it improves our business, is that rather than having to have infrastructure teams work with our application teams on a very long and complex process to help identify the security controls and the firewall rules that should be applied to their applications, we're able to take that - say, two-week effort - down to hours, using machine-learning, in order to construct those rules automatically.

ShieldX makes the cloud safer than on-prem deployments. That is because that the number-one cause of security incidents today is human error, and those errors are often a result of very complex security structures. ShieldX makes it a lot easier and a lot simpler to define your policies and define your rules, and that greatly reduces the opportunity for user error.

The primary features are being able to isolate and segment workloads, both within our data center and in the cloud, and to get visibility into what the applications are doing. The application visibility is the most important feature for us at the moment. The reason that it is so important is that we are migrating a lot of workloads from a legacy data center to a new data center, and that ability to have visibility into the application flows allows us to build the rules and policies for the newer data center.

The Adaptive Intention Engine is fantastic. It allows us to develop security policies using the language of our internal customers. It's machine-learning applied to security workflows. That allows us to much more easily construct the policies that will protect those workflows.

ShieldX also enables us to migrate to cloud environments faster. That is an important part of it for sure because it takes the exact same policies that we would apply to our on-premise environment and enables us to simply apply them to the cloud. It becomes one policy for both on-prem and for the cloud.

It gives us a lower dollar-per-protected-megabyte than a traditional firewall, but it's also consuming fewer resources in our network environment because we're not having to send our traffic out of the virtual environment just to send it back in. It also helps with lower maintenance costs.

The product is pretty good today. The areas of improvement are primarily going to be around resource consumption. With any kind of tool like ShieldX, where you're in the cloud instead of a traditional firewall, you're using CPU resources in those environments to provide the protection. So there's a cost associated with CPU resources. I'm pressing upon them to make the product much more efficient and use less CPUs to do the same thing.

The stability is very good. This is one of the strengths in the way that ShieldX works. They've essentially created a button to easily turn it off in case things are not running well. Honestly, it's been very stable, but we have a one-button click that will disable ShieldX from the environment in the event that it is going disastrously wrong.

We've never had to do that, but it's there and we've tested it and it works. I'm really comfortable with both stability and the ability to address problems in the event that the system isn't working well.

There are two parts to the scalability. 

The first part is that for virtual firewall-types of platforms, virtual security controls, and virtual microsegmentation controls, they scale better than anyone in the industry. The key differentiator there is that they've implemented what they refer to as microservices. In a traditional, virtual firewall - a Palo Alto, Check Point, or Fortinet-type of firewall - if you virtualize it, in the event you need more capacity, you're just adding CPUs to the firewall as a whole. ShieldX has taken every single service that is required to protect workloads and instantiated them as individual services that can individually scale.

That's really important because if, for example, SSL decryption - which is one of the most CPU-intensive functions - needs additional horsepower, we can provide CPUs just to SSL decryption, without having to provide CPUs to an entire monolithic firewall. That's really key to ShieldX's story and there's no one else in the industry that does that. I can scale horizontally as far as I can imagine. As long as I've got the CPU resources, I can continue to scale it. 

The second part is the downside. Compared to a traditional firewall, which isn't really a fair comparison, you're not taking advantage of ASICs. You don't have hardware-based firewall processing. You're dependent upon standard Intel CPUs, and that's where we want ShieldX to get more efficient in how they're using those CPUs so that we're using less of them.

We have about 2,000 servers currently protected. We will continue to grow. It's in the heart of our data center, so as we grow our data center, the ShieldX environment grows along with it.

We have used their tech support but because of our early adoption we have not been calling an "800" number. We've been calling the CTO.

Prior to ShieldX, we were using very traditional security controls, meaning traditional perimeter firewalls.

We switched to ShieldX because traditional firewalls are more expensive, and they require you to take all of your traffic outside of your virtual environment to inspect it and then return it back to the virtual environment. ShieldX lives inside of your virtual environment so it's able to protect your workloads without having to send them north to a firewall only to come back down south to another resource.

The setup is pretty straightforward. It's fairly easy to install. It's fairly to administer. It's intuitive.

Where it is complex is that you have to think about security in a different way, so you have to spend some time up front figuring out how you're going to define the tags that secure your resources. You have to think about how you want to segment your network, how you want to segment your applications in a way that's a little bit more abstract than what firewall administrators are used to. The complexity is not in the setup of the product itself but, rather, in the planning beforehand.

From install to testing to what we would consider production, it took about two weeks. There were about two months of planning ahead of that, but the actual deployment, where we were installing it, testing it, tweaking it, configuring it, was a couple of weeks. I would stress that our environment is complex and we were customer number-one. We were learning a lot through those two weeks. We could probably do it in two hours now.

Our strategy was to first put it into our QA environment, in a visibility-only mode. ShieldX can operate as just providing visibility, and then you can tell it to actually start enforcing the security controls. Our strategy was first to do QA, ahead of production, and, in both of those cases, to first do it visibility mode only. That let us learn about the environment, and let ShieldX learn about the environment, so that the Intention Engine could go to work. Then, in a future phase, we would come back around and enable the controls so that it actually started blocking bad traffic.

We partnered directly with ShieldX. Our experience with them was very positive. They have a fantastic engineering team. Again, we were customer number-one, so we were directly interfacing with the people who are writing the code and developing the product. That might not be normal.

With security, it's hard to articulate a return on the investment. It's a cost burden. We could probably say that it's a lower cost burden, but I think that we're a year out from being able to really determine that. I believe that it is a lower cost to operate. For sure it's going to be a lower cost to create the security controls. Probably in a year's time we'll know more. We'll see that our AppDev teams are able to build their own security policies, for example, but that's more of a vision statement than it is reality, right now.

Pricing is on par with some of the better firewalls. ShieldX's licensing model is based on bandwidth consumption, and that part is a little bit different. They're priced more the way cloud services are priced, which is a right fit for this type of product. You pay by the amount of workloads that need to be protected.

If you look at what it would take on traditional firewalls to do the same, ShieldX will be less expensive. The difference, though, and what enterprises are getting their heads wrapped around, is that it's licensing like the cloud, which traditional firewalls aren't quite like. With the latter, you buy a big box and you size it accordingly. So you do have to think about how much bandwidth is going through the ShieldX environment.

There is an issue that our company, particularly struggles with. I'm sure that we're not alone, but because licensing is, again, different, you're not buying a physical box. A physical box is capital asset. Because you're not buying a capital asset, and instead you're buying what is essentially a subscription license, you're taking costs that normally would've been capital cost and you're shifting them over to operating expense. Not all enterprises are set up to deal with operating expenses like this. Cloud has taken us there and it's forcing the conversation, but it is a change in paradigms. We're not capitalizing big pieces of hardware anymore. We're buying subscription services. There's a budgetary difference there.

We evaluated vArmour and Illumio. They didn't meet our requirements. ShieldX is a superior solution and I can give you the quick differences: Illumio is really an orchestrator so it's not providing security controls. It is managing the security controls provided by the operating system. It manages Windows Firewall, for example. vArmour, which is a closer comparison to ShieldX because it does provide security controls inside of the virtual environment, is one of those monolithic firewalls, so it does not scale as well.

The advice here really is two-fold. The first is a comment I made earlier. The bulk of the security incidents that are going to be made in the environment that security professionals will be working in, in 2019, are going to be caused by human error. More than 80 percent of all of the security incidents that were reported last year in the cloud were a result of human error. So my advice is to get a solution that is dead-easy to administer and one that is not being done in the types of controls that we're used to in traditional firewalls: IP addresses, ports, protocols. We've got to stop thinking about it that way and start thinking about the language of our customers, such as the applications that they need to protect, as opposed to the ports and protocols they need to protect.

Number two is that with a traditional approach to firewalls, you do not have visibility in east/west traffic inside of your virtual environment, inside of your data center, and it's no longer enough to simply segment. You've got to segment and secure the segments. Separating traffic isn't enough. You've got to put controls around the segments, meaning microsecurity in addition to microsegmentation.

If we go beyond security professionals, my advice to senior management, people like me, is going to be around making sure that you're prepared, from the top down, to be supportive of a change in model in security so that you are driving security through your AppDev teams and through your DevOps teams. What you really want to do is make it dead-simple, super easy for those folks to develop secure applications. You're going to do that by taking security and reframing it into the words and language that they use instead of the words and language that a network engineer uses.

We were an early adopter, and our company worked with ShieldX as they were launching the product, so we've been engaged with ShieldX for about two years, prior to the product launch, mostly helping to shape the vision of the product.

As far as who is administrating ShieldX, we have about a dozen people, and that would include traditional firewall administrators, but also our DevOps teams. The teams that are developing the automated pipelines to build servers, they're also using it to automate the application of the security controls. Staffing for deployment and maintenance is similar to how you would think about traditional firewalls. If I had a team of four people that were administering my firewall and security controls in a traditional environment, I'd probably still have the same, and that's about the number we have. They are security engineers.

I would rate ShieldX at eight out of ten. This product is hitting all of the marks for us. I would put it at a nine if the CPU utilization was lower. They're getting there and that's on their roadmap. It's a part of developing a new product. You first build the features and then you tune it and make it more efficient, so they're focused on efficiency right now.

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.

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.

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.

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. 

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.

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.

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?

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.

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.

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

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.

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.

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.

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.