What is our primary use case?
We are using it to segregate all of our different environments: staging, production, QA, as well as our applications. We are essentially replacing our traditional, internal firewalls and depending completely on Guardicore to secure all of our applications.
How has it helped my organization?
We've been able to secure older applications in a way that we really couldn't before, which has been a nice benefit.
It's also allowed us to build out an entire new data center topology without having to worry so much about where we place physical or virtual firewalls that can create bottlenecks. We can focus more on building a really fast and responsive network topology. Security devices, things like a traditional firewall, can often be a bandwidth or throughput bottleneck. But with Guardicore, since the firewall is running on every single server individually, and they're working together, you can just build a really big, fast, redundant network and not have to worry so much about those security bottlenecks.
What is most valuable?
The most valuable feature of this solution is the fact that it's pretty much agnostic to location. Right now we have an on-prem data center that we manage, but if we start to migrate into different cloud locations or multiple different clouds, we can manage all the security between all of the servers and applications, through one platform. That's a future, forward-looking bonus of it.
And right now, the real bonus is the fact that we can secure applications, all the way down to the individual services, on each host. It's actually more granular security than we can get out of a traditional firewall.
What needs improvement?
They're really good at getting into the environment. But the long-term management of the security policies could be improved with some kind of automation platform, something like Chef or Puppet or Ansible, to help you manage the policies after day-one. Setting it up initially is really simple and getting going is really easy, but to then manage the policies and changes to those policies, going forward, through some type of automation process is not turning out to be really easy. It would help if they could either provide some guidance there or adjust the way that the API handles that a little bit, to make that simpler.
Their API is clear. It's just proving difficult, from a code perspective, to manage the rule sets. You can build out a rule set really easily. You can deploy agents really easily. You can apply the rules, initially. The issue is then going back and adding a new rule to an old rule set or pulling one out and doing maintenance on it with code. It seems to take a lot of extra logical checks such as making sure we're not duplicating a rule or the like. That's really the only place where, although we're not stuck, we're having to put in more time than we anticipated. Everything else has been super-easy, but the maintenance and management of the rule sets with our automation tools has not proved to be as simple as we would've liked.
It seems like it would have been really easy to put it in if we didn't have a lot of changes. But it seems that the long-term maintenance of it is a little bit difficult and could use some improvement.
For how long have I used the solution?
We've had the Guardicore solution since May, so that would be about six months.
What do I think about the stability of the solution?
Overall the stability has been really good but there have been a couple of little bugs we've run into. Nothing has been negatively impactful to our traffic, it's mostly been a couple of cosmetic things.
Everything, so far, has turned out to be a really simple fix where they were able to get back to us within a day. We had an issue installing an agent on a newer version of Red Hat, but they had a solution already in place; it just wasn't rolled in. But they had it fixed for us within a few hours, and they actually had that fix in production within about a week. We've had a couple of what seemed to be visual bugs with the SaaS interface, with the web UI, but no service impacts.
Everything has been really stable. It's just that there have been times where you'll click on something and you would expect to see something there and it's not there, or it's listing more information than you would expect. Those have all turned out to be bugs, but I don't really fault them for that.
They've upgraded. We've only had it for six months and we've upgraded our aggregators and our SaaS instance two or three times. They're very proactive on updating and the platform is really stable. They just occasionally have a few little cosmetic bugs. I would prefer that than a company that either doesn't advance and make good changes or one where bugs have performance impact. The performance always seems really good; it's just a few cosmetic things once in a while.
What do I think about the scalability of the solution?
So far, scalability has been no issue at all for us. We did the proof of concept with a small group of servers, some 20 to 25. Within the first couple of days we'd deployed it to about 75 to 100. Now we're up to 200 servers. It seems to scale as fast as we can add agents to it and we haven't noticed any negative impact from going from one server to 200. And we don't expect any going from 200 to 1,200.
I think it would only be limited by the power of the SaaS instance and they scale that for you automatically on the backend as you take on more agents. If the SaaS instance requires more resources, they just provide that for you seamlessly without you having to do anything.
How are customer service and technical support?
I cannot not talk enough about their support staff. Their Professional Services team that we worked with for the first several months of the initial setup, are just absolutely wonderful; some of the best I've ever worked with. We've recently been handed off to their customer success team, which is the long-term support, once you're onboarded with the platform, although we haven't even been cut off from our Professional Services team. I still talk to both: the original engineer who helped us set it up and now I have this new customer success staff. They are amazingly wonderful, so far.
I've never had to wait more than half an hour for some response, and usually have a solution to any problem I have by the end of the day. For every issue we've had, if we start in the morning with an issue, it's really been almost same-day service. We haven't had a ton of issues, but their responsiveness and their attitude and their willingness to help have been greatly appreciated. We deal with a lot of vendors and some are better than others. Guardicore is really top-tier in their customer support. I can't say enough good about them.
How was the initial setup?
They provide really good documentation on agent deployment. They told me through the setup that the thing that most organizations usually struggle with the most is getting the agents deployed. But we found that—probably because we were already doing some automation—was really quite simple.
Overall, it was really easy to get up and going. We installed the on-prem aggregator that bridges the agents on the servers to the SaaS instance, and then you just install the agents. We were actually able to deploy 50 to 100 agents within a day. And once we could deploy 10, since we are already automating a lot of our package management on our servers, we could've done 1,000 or 2,000 in a day. We could have done it on as many servers as we have.
They provide you all the tools. If you're already automating your servers, it's a super-easy solution to implement. If you aren't doing automation and are still manually managing all your servers, one at a time, I can see that it wouldn't be quite as easy as it was for us.
We are still in the process of deploying it across our company, but to get it up and running, it took less than a couple of days. Right now we're at about 200 servers, but we expect to grow to around 1,200.
To initially get it up and running and have everything working, took only me, in my role as a manager of network and security engineering, and one member of the server team. You could really do this with one or two people, as long as you have a network guy and a server guy. But now that we're deploying it more widely, there are six or seven main players in our company who are involved in writing the scripts and doing the automation work to get it deployed and to manage it.
My team was in charge of the initial setup and getting the policies built and the rule sets created. And the server engineering team is handling the agent installs and making sure they're checking in with the SaaS instance, and they are also putting the Guardicore labels on the agents. They say, "This is a Windows Server, this is an application server." And then we maintain the rule set that controls traffic, based on those labels. It's a two-prong management solution.
What was our ROI?
I know the ROI is going to be there because I know what the future's going to look like. The only reason we haven't seen as much as we possibly could have is all on us moving slowly. It's not anything to do with Guardicore. I'm really hopeful for the future with them. But right now we've only really secured a handful of applications. That's all gone really well, but we definitely have not realized its full potential. We've got a lot of older applications and it takes time to get people to agree to rebuild the server and put the agent on it.
We're trying to shift all of our servers. Instead of applying it in place, we're actually trying to go through a process of rebuilding all of our servers. During that process we'll move an application from an old server to a new one, put the agent on it, put it in the new network, and then it will be a Guardicore protected area. That's a slow process that we have imposed on ourselves. I see the light at the end of the tunnel. I think it's going to be a great solution but we are far from the end of the road with realizing all the benefits. That's just a result of taking our time and the plan that we created for ourselves.
What's my experience with pricing, setup cost, and licensing?
They worked with us really aggressively to get the business and we felt we got a pretty fair deal with them. They were really flexible with our limitations on currently available funding versus future funding. They were really nice about restructuring the purchasing contract.
We did a "step-in" model where we committed to a three-year deal, but we would pay a small amount in the first year, a little more in the second, and ramp up to full price, year-over-year, by year three. That had to do with money that was available and budgeted for at the time. They were really good at working with us on that.
They have been generous with the licensing. We were only supposed to be able to have 200 licenses in the first part of the first year, and then it would ramp up to 600 and then ramp up again to 1,200. But they've assured us, over and over, that they will not complain if we go over any of those limits before those dates. They're just glad to have us as a customer. We're already committed via contract to get up to that 1,200 number and to be paying full price.
They've been really flexible with the licensing, with the contracts, and everything else. It was a good experience. And compared to the pricing we were seeing from both Illumio and Edgewise, Guardicore was very competitive.
There was a $19,000 upfront cost for the Professional Services engagement, in addition to the licensing, but that was the only extra cost that I'm aware of.
Which other solutions did I evaluate?
We looked at Illumio and we also looked at Edgewise Networks.
At the time, Illumio was manipulating the built-in firewall of either Windows or Linux. They were essentially just going into the OS and taking over the management of the local firewall, which was good in some regards but it seemed like an older way to do the same thing. Edgewise and Guardicore were more in step in that they actually have an agent that sits between the compute kernel and the networking layer and that manages which sockets are open and how the services are able to talk to one another. That seems like a better and more modern approach. That was one thing in their favor.
We liked a lot of features of both Edgewise and Guardicore. It came down to cost, in the end. We got a better deal with Guardicore. There were a couple of features that I felt meant that Guardicore had more going for it. It seemed like a little bit more of a mature solution at the time. It had been around a little bit longer. It felt like it had some more depth of knowledge and stability, given some of the engineers we spoke with.
Edgewise was very new. Since we talked with them they've actually been acquired by NetScaler. We had a little bit of apprehension in investing in something that might get gobbled up or might fail, because it was a new company. They're both good solutions but we've been happy with the choice that we made.
What other advice do I have?
Think of all the possible scenarios that could apply to your network traffic and make sure you test those thoroughly in your PoC. Think about things like clustering, broadcast traffic, and all the different ways you want to be able to either restrict or group traffic. Run through the gambit of scenarios that you could imagine wanting when segmenting your network with a microsegmentation tool and test all of those as much as you can.
We haven't run into any issues, but there have definitely been some instances where we assumed the product worked one way and, as a result, we went down a path for a week or two writing rules in a certain style, or grouping things a certain way. But then we came to realize, "Oh, that's not really the way Guardicore is intended to work, and it works better if you do it this way." So test, test, test. Make sure that you're confident that it's going to meet your needs.
There's nothing that they've advertised or told me that it can do that it can't do. It's more my understanding of how to implement it. They're flexible, so it's almost like they give you enough rope to hang yourself with you. You might want to talk to them about your philosophy a lot, upfront, before you even start to really commit to a direction regarding how to build your rule sets. If they understand what you're trying to do, they can probably guide you on the best way to get there.
We just picked it up, thinking we're technical and smarter than we are, and ran down one road and when we got there found, "Oh we should have done it this way." And when we stepped back and looked we said, "Oh yeah, that makes a lot more sense." Then we had to go back and undo some of our work.
So work really closely with the PS guys, explain what you're trying to accomplish and be open with them, and they will help guide you to the best way to implement the product.
I would give Guaridcore an eight out of 10. It's a really great product. There is probably room for them to make improvements. Obviously, they're always adding new stuff. The biggest hindrance we've had is a lack of resources to dedicate time to the project, and none of that is their fault.
It's more a matter of making sure you're pushing all of your projects forward with Guardicore in mind. If you're going to have it wrapped around all your applications, you need to make sure you're writing your apps in a way that is going to work well with Guardicore, or that you're building your network typologies in a way that it's going to work well with Guardicore. If you're going to go all-in and put it on all your servers, you have to factor it into all your decision-making. And I wouldn't say that's a negative, but that's the main takeaway, now that we've gone down this road. You really have to think about Guardicore's intended view of how the product should be used and make sure that you're building along with that, so that you don't come to a crossroads with the tool when you're trying to secure your application.
They're definitely keeping up with new technologies, their deployment is easy, and their customer support is great. I really don't have a lot of negative things to say about it.