We use it to control privileged access within the environment, including domain admins and server admins.
We're using the CyberArk Privilege Cloud version, which is the PaaS.
We use it to control privileged access within the environment, including domain admins and server admins.
We're using the CyberArk Privilege Cloud version, which is the PaaS.
It provides a one-stop shop for the majority of our administrators to get the privileged access they need. It has enabled us to reduce risk as well, and that is the largest benefit that we've encountered through the solution. We've reduced the number of admins in our environment significantly.
It provides an automated and unified approach for securing access across environments, including hybrid, multi-cloud, RPA, and DevOps, as well as for SaaS applications. For what we're using it for, it's doing all of that seamlessly in one place. It helps us to quickly adapt and secure modern technology, and that's another reason we chose CyberArk. They already had integrations with solutions that we were either moving toward or that we already had. We weren't going to have to do them as customizations.
The ability, with Secrets Manager, to secure secrets and credentials for mission-critical applications means people don't have to go searching for them. They know where they are—they're in CyberArk—so they don't have to go to a separate place. They have one identity to manage, which is their single sign-on identity. From there, they can go into CyberArk to get the access they need. That's an area that has been very helpful. And from a risk perspective, the multifactor authentication to get to those accounts has also been awesome. That helps us to be in compliance, as well as secure.
The Privileged Session Manager has been the most useful feature because we're able to pull back information on how an account is used and a session is run. We're also able to pull training sessions and do reviews of what types of access have been used.
We also use CyberArk’s Secrets Manager. Because AWS is the biggest area for us, we have accounts in AWS that are being rotated by CyberArk. We also have a manual process for the most sensitive of our AWS accounts, like root accounts. We've used Secrets Manager on those and that has resulted in a significant risk reduction, as well. There's a lot to it, but from a high level, we've been able to get some things under control that would have been difficult otherwise.
For DevOps, we've integrated some automation with CyberArk to be able to onboard those systems. There are some native tools like the CFTs that we're using with CyberArk to get CyberArk deployed automatically to them.
It also gives us a single pane of glass to manage and secure identities across multiple environments; a single view with all of the accounts. It's super important for us to be able to see all of that in one place and have that one-stop shop with access to different environments. We have lots of domains because a lot of acquisitions have happened. It's important for us to be able to manage all of those environments with one solution and we do have that capability with CyberArk.
I've been using CyberArk Privileged Access Manager at this company for two years, and all together for the past six years.
The stability is great. We haven't had problems with it.
The scalability is very good. I'm surprised they keep as many logs and video recordings as they do on their side. But scalability hasn't been a problem. If we wanted to scale up, we could certainly do so. All we would have to do is add more servers on our side, with our PSMs (Privileged Session Managers). The way the solution is built out, you can expand it elastically pretty easily.
We have around 400 users right now who are mostly in IT. There are developers, database administrators, as well as our Active Directory enterprise teams, and some of our cloud implementation and infrastructure teams. We have some in incident response people, from information security, who use it as well.
We're looking to expand it in the coming year. We've already started that expansion. It's the developers we're targeting next and there are a lot of them. We're looking at a couple of hundred more users within a year.
If there is an area that has room for improvement, it's probably working with their support and getting people on the phone. That is hard to do with most products in general, but that seems to be the difficult area. The product is fantastic, but sometimes we want somebody on the phone. I would rate their support at eight out of 10, whereas the rest of the solution is a nine or 10.
From a technical support perspective, they've been really good. There has just been a little bit of trouble with the database stuff, but that's because ours is a very aggressive deployment. Sometimes, when working with support, they aren't as aggressive as we are.
I've used Thycotic and Hitachi HiPAM, and we've used some custom in-house build solutions.
The reason we switched is that Thycotic opened up the door to that possibility when we talked about pricing. The price came out to be something similar to what we were spending. We were basically going to have to redeploy the whole Thycotic solution to get what we needed, and that opened it up for us to evaluate the landscape.
There were some complexities about the setup, but deploying a solution like this is going to be complex, no matter what solution you go with. CyberArk did an excellent job of making sure that we had everything we needed. They had checklists and the prerequisites we had to do before we got to the next steps. Although it was complex, they were complex "knowns," and we were able to get everything organized fairly easily.
Our initial deployment took about two weeks.
We broke the deployment into four phases. The first phase was called Rapid Risk Reduction, and with that we were getting our domain admins under control, where we went with domain admin, server admin, and link admin. A part of that was the server administrators and Linux administrators. All of that was part of a very short-term goal that we had.
Phase two was called risk reduction, where we were focused on Microsoft SQL, the database administrators, and Oracle Database administrators. It also included bringing in some infrastructure support as well.
Phase three was enterprise-grade security, and with that we've been pushing the network tools and AWS admins, along with some other controls.
And our last phase, which we've just recently started on, is one where we are going to be pushing hard to get developers onboarded into CyberArk. There are a whole lot of little details that go along with all of that. The initial auto onboarding happened in phase three, but we also have auto onboarding that we're looking to roll out across a larger group.
We implement least privilege entitlements as well. We started out from a high level of not going the least privilege route and, rather, we locked things down in a way that they were managed, at least. Then we started knocking down the least privileged path. You have to start somewhere, and least privilege is not going to be the first option, out of the gate. You're going to have to take stepping stones to the best practices. And that's what we've done. We took this large amount of high-risk access and brought it into CyberArk and then pulled access away over time and have been making things more granular, when it comes to access to the systems. The access within the systems, within CyberArk, is absolutely granular and we have been very granular with that from the beginning.
For maintenance of it we need about one and a half people. My team supports it and, while one full-time person is probably enough to support the solution, my team is split up. The general operations of CyberArk are what take up the most time. The actual running of the solution, from an engineering perspective, is very lightweight; it's hardly anything.
We did not use a third party for the deployment.
We started doing some comparisons of different tools and that's why we ended up switching to CyberArk, after discussions with both Thycotic and CyberArk. When looking at the capabilities, we ended up moving towards CyberArk. We felt it was a more mature solution and that some of the connectivity and reporting was done in a way that we would prefer, for a company of our size.
Thycotic is a good tool. A lot of IT people already understand the structure of how it runs. The upgradability is nice as well. You can just click an "upgrade" button and it upgrades the solution for you. The cons of Thycotic include the way that the recorded sessions are done. In addition, proxy server connections were not available. Maybe they are now, but at the time we were building out custom connectors and we had to go through a third party to get those developed. It was very bad and every step of the way was like pulling teeth. That really soured our relationship with them a bit because we couldn't seem to execute with that solution. When we started talking with them about what we needed it to do to make things easier, they ended up recommending a full redeploy. That's not ideal under any circumstances for anyone. That's why we took a step back and evaluated other solutions.
With CyberArk, some of the pros were that their sales team and engineers were very quick to come in and help us understand exactly what we needed. The deployment timeframe was also much shorter. We didn't have to work through a third party, as we would have had to with Thycotic. And the type of relationship we've had with CyberArk is one that I wish we had with other vendors we use. They've been phenomenal working with us.
CyberArk's abilities are amazing. We're just starting to hit some limits, but we're able to get through the majority of them. Some of the database stuff is a little bit more involved. The other things, like cloud and all of the Linux and Windows, have not been a problem at all. It's not that the database stuff is a problem, but it's just more complex.
If you want to talk about CyberArk providing an automated and unified approach for securing access for all types of identity, "all types" is a strong claim. I wouldn't ascribe "all types" of identities to anything. But for everything that we're doing with it, it has been a great tool and it's doing that for us.
We are an integrator, and we do a lot of Identity and Access Management and Privileged Identity. I am only just getting into this solution. I am not trained in it, but I've been reading about it. I have recommended it for a client based on their requirements and based on what I know about CyberArk versus a couple of others. I have not implemented it yet. I have the agent running on the system where I am actually profiled. I have its latest version.
What I liked about this solution is that it can also integrate for tracking malicious use or sending analytics to a host that can process them. I don't know if CyberArk, Centrify, or Thycotic can do that. The analytics was something the client really wanted, and they already had BeyondTrust.
It is very scalable. The agent on the workstation is very thin, and the processing power required on a server is nothing out of the ordinary. It is also very stable and easy to deploy.
What's bothering me, which is true of all of them, is that sometimes, the error codes that come up don't necessarily get reflected in the searches within their support sites or they're out of date. I would rather search by an error code than type in the text and search for it by text because the error code means that it is programmatic, and it is known. It might not be desired, but it at least is not unexpected. If you don't have an error code, you just get an anomalous error, and if it is lengthy, it can be difficult to search and find the specific instance you're looking for. This is something I would like all of them to improve. BeyondTrust, CyberArk, Centrify, and Thycotic could do some improvements in staying up to date and actually allowing you to search based on the product version. They are assuming that everybody is on their way to release. They put out a new release, but it is not reflected on the support site, which makes no sense to me, especially when they revamp all the error codes. They all have been guilty of this in some way.
I started using it about a month ago when I was doing the appraisal of it, and I put it on a virtual machine. Our work machine is a virtual machine.
It is very stable. I had worked on a competitor's product two years ago, and it was rather buggy. It had issues. Sometimes, it used to hang the machine. Because you're running an agent on the workstation, it could have a memory conflict or an application conflict. It doesn't happen anymore because you've got it pretty much running strictly in Windows.
It is very scalable.
I used their email support, which is very good.
I didn't switch the client to this one. I recommended this one because it stays under the BeyondTrust umbrella. It also helped them in getting a discount for volume and being a loyal customer and things like that. They also didn't have to add new infrastructure.
CyberArk is a very good product, and I like it. I've been trained in it, but I have not implemented it. I am not going to ask the customer to install another infrastructure or another platform, especially when the products are fairly equal or equal enough to not be an issue to put on a table. If I had recommended CyberArk, they would have to put in a CyberArk infrastructure and retrain a whole bunch of administrators to administer that. They would also have to train a whole bunch of support people to manage off-hours, holidays, weekends, and things like that. Every time you add another brand, it adds to your soft costs, which can make a solution pretty expensive.
Hard costs are so much fun, and they're much easier. I've seen people get up and just start writing on a dry erase board because they know all the hard costs. It would be good if they would just be honest with themselves and the clients and explain what some of the soft costs are in terms of additional training or a more significant hardware footprint.
It is pretty straightforward to get the agent installed. You install the agent and the server component, and you let the users do whatever they've been doing for the last 10 or 20 years of their life. You also create profiles. For example, I had a developer profile for both Windows and Linux, and I had a profile for a regular user, help desk, and engineering. After you create profiles, an administrator can look at their activities in the log and analyze things like the following:
You can then add things like this to your blacklist, and you can create a profile that will allow or disallow that.
I would rate BeyondTrust Endpoint Privilege Management a nine out of ten.
There are a lot of customers, worldwide, who use this solution, especially in the education sector. This solution is so niche that it's not like TeamViewer. It's basically designed and developed with enterprises in mind—it's an enterprise solution. It's built for a highly privileged and secure environment. It starts with a virtual appliance and physical appliance and then, now, to what's basically a cloud-based type of access.
One of the most valuable features is that this is a product designed with enterprises in mind.
I think that BeyondTrust Password Safe could be improved with more testing. In the beginning, they were practically using customers as beta testers.
Maybe the product has evolved since I last used it, but if you look at PAM, privileged access management, whatever's out there has already been done. I don't see there being any other enhancements that are being made regarding PAM, except to support more cloud-based applications.
I have been working with this solution for over 10 years.
The early version of this solution was not stable. It was terrible, but I think they eventually got their act together and it's better now so that they can compete. I haven't tried a cloud version, but if you imagine a solution is 100% on-prem and suddenly turns to the cloud, you can imagine there will be a lot of testing and bugs and all that. I'm not saying the product isn't good, it's just that when you have a vendor that starts out on-premise and only turns to cloud in the past couple years, they have a long way to catch up to leaders such as Thycotic or Centrify.
You've got to patch it every month, so how could that be stable?
This solution isn't really scalable because it's Windows-based. How could any Windows solution be scalable? This is strictly my personal opinion, but I would believe that about 80% to 90% of people will agree with me. Windows platforms aren't scalable.
I think that customers could see an ROI eventually. A lot of customers purchase the product because they have to get something implemented for GRC: governance, risk, and compliance reasons. So, if you don't buy any of them, then the auditor will say that you didn't pass the audit because you don't have that mechanism in place. This solution is expensive. Is it worth ROI? Yes and no. If they have to meet compliance and whatever standard requirements, I would advise the customer to at least look at two complete products first. This wouldn't be my first choice.
This solution is not cheap—it's a very expensive solution. Very, very expensive compared to the features and functions that they offer.
This solution is competing with Thycotic and Centrify, the leaders. Only in the past couple years did BeyondTrust turn from 100% on-prem and start offering cloud services, so of course they still have a long way to catch up with them.
I rate this solution a five out of ten, to be neutral and in the middle. To those looking to implement this solution, I would advise them to fully test it out in their environment before even making the purchase. You've got to thoroughly test it—test everything, otherwise you might regret it.
It is primarily being used by our application for most of its application secrets.
All our workloads are running on AWS, so integration with our workload is much easier on AWS Secrets Manager than going with another solution such as Thycotic.
The API interface provided by AWS Secrets Manager is much easier. AWS provides you a good set of APIs that you can interact with using Python, Java, etc. Access control is also completely possible on AWS.
It is an intuitive product. It is working well for our use case. We haven't seen any scenario where we are not able to use it.
If you don't have enterprise support, then you will not be able to get through to them to get the help. It is not only applicable to AWS Secrets Manager. It is also applicable to any service on AWS.
I haven't heard of anything from my operations team with regards to any errors or any issues detected on AWS Secrets Manager. The access has been smooth. We have a lot of API integrations with AWS Secrets Manager. We haven't heard of any specific errors.
It is an AWS-managed service. All AWS services that are managed by AWS come with their own scalability options. They are scalable by default. We have never faced any scalability issues. That could be because the number of requests that we are sending to AWS Secrets Manager may not have actually reached the max limit.
We have five or six applications that are integrated with it within six months.
We have an enterprise account with AWS. They are good not only with AWS Secrets Manager but also with other products. We do get good support because we have an enterprise account. If you do not have an enterprise account, they do not provide you the support that you need. They push you to come to the enterprise account.
The setup is straightforward on AWS Secrets Manager. It is a managed service. They manage it, and we don't deploy it anywhere. It is not the kind of solution that we deploy. We just provision it and use it.
If your workloads are running on AWS and you want a quick and easy integration with a solution to manage your secrets, AWS Secrets Manager can do the job. If you're not hosting your application on AWS or you're trying to do something on-prem, AWS will still be able to solve most of your issues, depending on the use case. It certainly cannot act as a PAM solution.
I would rate AWS Secrets Manager a 10 out of 10. Everything is good, and I have not had any issues with it. It is a part of the overall workload. It is just a piece of interface for us to save the secrets.
We use BeyondTrust DevOps Secrets Safe to manage all the user accounts.
The local administrator can manage all the user's logins in one, simple, straight-away account access. Additionally, the solution is user-friendly.
I have been using BeyondTrust DevOps Secrets Safe for approximately three years.
The stability of BeyondTrust DevOps Secrets Safe is good.
The scalability of BeyondTrust DevOps Secrets Safe could improve.
I would rate the scalability of BeyondTrust DevOps Secrets Safe a seven out of ten.
We have one client using the solution.
The support for the solution is not very good, they could improve by being quicker.
I have used previously Delinea. I would recommend Delinea and BeyondTrust DevOps Secrets Safe to others.
The installation of BeyondTrust DevOps Secrets Safe is at a moderate level of difficulty.
We have one engineer that does the implementation and support of the solution.
There is an annual license required to use BeyondTrust DevOps Secrets Safe.
I would recommend that before they use the solution they do a POC.
I rate BeyondTrust DevOps Secrets Safe a seven out of ten.