Our administrators mainly use it to protect their different packages and access secrets through Safeguard, either by checking out credentials, using encrypted sessions, or utilizing the product's API.
We are using a virtual appliance deployed in the cloud and on-premises.
The centralized storage of secrets and credentials prevents them from spreading throughout the organization. We know who has control over them and who has access. Before Safeguard, there might have been a few Post-Its stuck on screens, which isn't secure.
We have also gained visibility into the use of privileged access. It's way easier for us to see what, when, how, where, and why. We now have a good way to provide justification for doing things, instead of relying upon people to remember. Now we can demand that.
And the rich level of logging, including visual logs with video recordings of sessions, has given us more confidence in our security posture, where we have onboarded the system.
The whole product solves the privileged access management challenge for our company. We have a secure tunnel, a secure session manager, and automatic logging of sessions, which is good for forensic purposes. We have a rich level of logs and can trace what happened on which machine and see who did what.
Feedback from our users on the usability is positive regarding the UI experience. Instead of keeping their credentials on them somewhere, they now have a very easy-to-use portal with a nice GUI. There has been some feedback from people saying, "Couldn't it do this," or "Now I have to do that". But that's basically change management and not a real problem. There is some getting used to the UI, but I think the UI is very easy to understand and to use. The usability is very good and that's one of the main ways Safeguard stands out from the competition.
Safeguard, the way I see it, has two different parts: vaulting and sessions. And those two are running on different platforms. The vault itself is a locked-down Windows box, which isn't really causing any trouble. The session part is on a Linux box. They sell them separately, but together, they need to be more unified, at least from a UI perspective when you're using it as an administrator. There are some "legacy-level" menus and ways of using it that I don't really appreciate.
We are using it completely web-based, not through a fat client. The browser experience of administrating SPS (Safeguard for Privileged Sessions) needs a lot of attention from an administrative perspective to make it easier. The readability of the system itself is quite poor.
A user never really engages with that part. It's only the administrator, and maybe an auditor, who are subjected to using those menus and tools.
So the SPS could be a lot easier to administrate and the parts should be unified, from a design perspective, so that I can recognize the systems as being part of the same package. They feel like they have been forced together.
We started implementing One Identity Safeguard about one and a half years ago.
It's very robust. We haven't had any issues with Safeguard's stability.
We have done a few things that have "annoyed" it, but it has always come back. We tried to upgrade one of the session nodes, and we did it in the wrong order, but it pulled through anyway. That was quite impressive. If you deploy it on virtual servers as we have, with a virtual appliance, if you have that under control, Safeguard itself is not an issue, at least for the time being.
I believe we may have done a bigger deployment than we actually need. We were advised to use a node and another node to have a little bit of a cluster function. We went even bigger than that, so we are using the biggest version of what they recommend.
But I don't see scalability as an issue. I don't think it's something that Safeguard does particularly worse or better than anyone else. It's easy to deploy another node for the same function that you already have. Or if you want to replace something that doesn't work the way you want it to, you can switch it. It is very scalable. We haven't touched the limits of what it's capable of and I don't think we ever will.
We have about 150 users at the moment.
I don't think we are using One Identity's Premier Support. We are using some level of support from them, but that support is handled by our partner. If we raise an issue, our partner coordinates between us and One Identity.
We did not have a previous solution.
There are different kinds of solutions that Microsoft provides, called PIM, instead of PAM. It's for cloud-based roles and privileged access. We were using that before Safeguard and we are still using it for that specific use case. But we didn't have another privileged access management solution, other than human administrators. It was surely needed.
Just getting a PAM solution is many steps better than what we had before.
The initial setup wasn't really complex. We are using the virtual client, so it was fairly easy. We didn't really have to do any setup. We just had to start a virtual machine and run the appliance, following their documentation, which is very good. It was quite easy.
We are utilizing a partner for getting started so I didn't find it hard to start.
Among the things that you need to look out for, and this applies to every product, is how it fits into the network that you are going to put it in. There are a lot of specific ports that it needs to be accessed through, and you should probably keep it as locked down as possible because this system shouldn't be exposed to any other environment. That is a hard task to complete. That is not a fault of the product itself, but it comes with that can of worms.
And, of course, you have the certificate questions, the different certificates that it needs to validate sessions and keep them secure. That's quite tricky as well. Again, it's not really a Safeguard issue, but your organization needs to know that these are considerations when you start.
Our technical go-live with the solution took three or four months. That was mostly related to our network issues and finding all the different ports that needed to be opened and closed. But starting the application and using it, running the GUI itself, is a matter of days. It depends on your organization and how well-equipped it is for this type of change.
We didn't force any big changes. We were debating if we should onboard our current privileged users and then force them, from day one, to use the system. Instead, we did a side-by-side solution where we started alternative users on it and then told our previous users to use it instead. And if that, somehow, was not satisfactory, they could still use their old account to complete the work. That way, we didn't jeopardize production. Every time we received feedback such as, "I need to use my old account because I cannot use this new Safeguard version," we needed to adapt and improve.
Once there were no more complaints, we started shutting down the old users who had not been onboarded to Safeguard. We didn't want to bring major change in an instant. We led them to the Safeguard solution and let them try it out, give us feedback. Generally, they found it easier to use Safeguard compared to their old ways and they started preferring it. When we saw we had no risks left, we disabled the accounts that they were using before.
In terms of training, for the admins we had a five-day course, which covered the basics. I did not receive that course, but I didn't really need it. The right partner can explain enough to you, in small sessions, about what you need to accomplish. And the user experience itself is so intuitive that you understand what you're doing. And their documentation is very easy to search and use. You don't really need much training. Of course, you need to understand how you affect different systems if you connect them to Safeguard but that depends more on your own organization than on what Safeguard is.
End-users just need a basic introduction to tell them, "Please go here, use this." They log in with known credentials and the same password as everything is under MFA. It's nothing new to them. And the user experience is very simple for them to check out the privileges that they need for the moment that they need them. That's quite self-explanatory.
We had a partner called Intragen International that helped us understand the best practices for deployment and what not to do. We had them as an adviser, but we performed every step in-house. They didn't have any access to our system. They were more of an adviser.
I believe we have a five-year deal in place, and it's an all-you-can-eat license. It's not user-based.
We also pay our implementation partner. We have a support deal set up with them, so that's a cost we have added on. But it's not applied to the Safeguard bill. The advisory role that they provide us is something that we decided we need.
We looked at the product from BeyondTrust. And we looked at CyberArk because that's what you need to do when you start this process. We also looked at a couple of other products, market leaders, according to review sites. But we mainly looked at CyberArk.
We, as an organization, realized quite early that privileged management access is hard. There were solutions that, like CyberArk, were very advanced and had huge legacy support with every type of system known to man. That was very interesting because you never know what you might have. But when we looked into CyberArk, we also felt that the system was a leader because they were first, not because they were the best. It seemed to be quite complex to deploy. Knowing our limits, we felt the Safeguard solution was more of a fit for us, and the user experience was way more intuitive than the CyberArk version.
Looking at the other competitors, they were more leaning toward a cloud-based solution or were going that way. Of course, we are always trying to get to the cloud—you never get there, but you always talk about it—and we felt that if we were going to keep all of the secrets of the company anywhere other than in our own environment, it would almost be irresponsible to have it on a vendor that always puts things in the cloud. That essentially meant we wouldn't know where they would be.
By deploying it ourselves, at least we know where the keys to the kingdom are, and we control them. The other vendors were not selected because they were too cloud-oriented for such an important part of our company. We needed to keep it ourselves and keep the responsibility in-house, and not put it anywhere else.
Safeguard had the same philosophy, allowing us to do a virtual appliance that we deployed ourselves in our own data centers, keeping every bit of information inside our walls instead of putting it on the cloud. With CyberArk, we could do that as well, but it sure seemed way harder, so we skipped that.
To prepare for Safeguard you need to know your network, and if you think you do, you don't. You need to have network personnel available during the deployment to maintain tempo in the deployment. If you don't have access to people who are able to change things in the firewalls and the like, you will stall.
The documentation, what you need to do, is very clear, but every network is different, and you really need to know where you put your Safeguard solution and that you have access to people that can help you fit it into your existing network. That's a very important step.
You also need to know what "high privilege" means to you because it's not defined in Wikipedia. You cannot go there and see what applies to your systems. You need to know that yourself. Be sure about what you want to protect and what levels of protection you want, beforehand.
And, as I mentioned, there is the issue with certificates, which is an issue for every company. It's quite a hard thing to know. Not everyone is a professional when it comes to certificates. You may need to know the certificate chain, and you might have to update it with new information and roll that out to your organization. That might not be your first thought when implementing it in your system.
But the main focus is the network, especially if you're also going to deploy Safeguard in your own cloud. That creates a little bit more of a challenge.
We use their product called Active Roles as well. We haven't really done any integration with other parts of our business. We have just given administrators and people with high privilege a secure way to access their systems through RDP and SSH. But we have not integrated any robots or development flow as of now. We are too young in this journey.
