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.

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.

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.

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.