Hello, welcome to this webinar from KuppingerCole, sponsored by Syteca, formerly Ekran Systems. We still have to say that. We're talking From Detection to Recovery, PAM's role in incident management. Perhaps we should say PAM's emerging role. To talk about that, I'm delighted to be joined by Aleksandr Dymov, who is a product manager at Syteca.
Hi, Aleksandr, how are you? Hi, Paul, nice to meet you. Thank you.
Okay, so just for you watching, just a few pointers. You don't have to do anything. You're muted. You don't need to mute or unmute yourself. We'll do a couple of polls, the first one in a minute, and then we'll look at the results of both at the Q&A session at the end, and there will be a Q&A session at the end. The webinar is being recorded, so any of your colleagues who might have missed it can watch it, or you can watch it. If you think it's that great, you can watch it again. So here's the agenda.
So I'll talk through a little bit generally about privilege access management and where it's going, including things like incident management and also where I believe it fits in this new paradigm of putting data first. Then Aleksandr will talk a little bit. He will also give us a live demo of the software, which is great, and then finally it's your chance to ask questions and wrap up, and then we'll have also within that the final poll. So as I said, here is the first poll, just a general one, really, to ask you what you believe is one of the most important features in PAM.
So is it granular access controls, real-time risk assessment and action blocking, seamless integration with existing IT systems, or advanced audit and reporting capabilities? My apologies for the noise in the background there. So that's granular access controls, real-time risk assessment, seamless integration, or advanced audit and reporting capabilities. So we'll leave that up, and I will start with my part of the presentation.
So this is really just the kind of stuff you probably already know, but privilege access management and how it fits into modern security and modern organizations, and, of course, it is now considered a cornerstone of cybersecurity. It's become more and more important over the years as the way that we work has changed, the way that more and more identities have been evolving, and how the need to give more and more users, machines, et cetera, privilege access. So PAM has gone from being like a fairly niche application when it first started to being something that is essential.
Before, it was pretty much just for administrators, et cetera. And part of the reason for that is, again, because of the complexity of the IT environments that we have now, the identity sprawl, et cetera. But I think what we'll be talking more about on this webinar, and particularly Alexander, is that PAM now needs to go a bit beyond just protection and start getting involved in instant response and reporting.
So it's always done a bit of reporting, but I think we're looking now for more dynamic and more up-to-the-minute types of reporting so that we know what is happening to identities trying to get access to privilege resources. So that's where we are right now.
And then, again, here is some things that virtually all PAM solutions currently have. So they will have a vault. They'll have vault for credentials and for rotation and management of those credentials. Session monitoring and recording.
Again, this previously has been a rather static thing, so it's kind of you can always see afterwards what happens, not what's happening right now. We've seen in recent years the emergence of capabilities that allow users to find privileged accounts, to discover, and this particularly is where we see some crossovers with cloud infrastructure entitlement management and where you can use PAM to discover entitlements in cloud particularly or put out cloud specifically.
Traditionally, PAM has been based on role-based access, so the decision to give a user access to something has been based pretty much on just the role that they're doing, but we're seeing that that is actually quite limited now. It works still for perhaps areas like the traditional admin privileged access, but we need something, again, more dynamic and more in tune with the circumstances of not just the network but the circumstances of the identity at this precise moment that it's looking for access. So we're talking about attribute controls and things like that and also policy controls.
And multi-factor authentication has long been an integration, so with PAM you will find that a user will be given access but has to go through a different number of factors perhaps to prove they are who they say they are. So that's what's common now. But this is really what we're talking about now, which is the emerging capability. PAM is sort of developing now. It's maturing. And we're looking more at protective stuff. So it's looking at it from the outside now before an access or request has been actually given.
So we're looking at tools that can prevent unauthorized access right from the start and minimize risks before they even get anywhere near the network. We're also, with the emergence of superior artificial intelligence tools, we're now seeing analytical requirements that go beyond the sort of traditional session management and recording history. They can also look at stuff much more quickly and can actually pull out root cause analysis. They can pull out what happened, why, who did it, et cetera.
So we're seeing a shift from a preventative-only mindset to a more proactive response model for privileged access. So it's all becoming up to speed, I guess, with the way that we're now working with cloud, the way that we're now working with collaboration tools, and the way that we're working with all sorts of identities, including, of course, those that don't actually perhaps work for the organization directly. We're talking about contractors. We're talking about temporary employees.
And, of course, we're talking about all those machine identities which are coming on stream. So how do we streamline incident response or incident reporting? If something happens, you need, if it has happened, then you need to be able to find out what happened as quickly as possible. You need to be able to tell the compliance, the auditors, the investigators, anyone that has an interest, stakeholders, how something might have happened. And you also need to be able to see that in real time. So it might still be happening.
You know, you might not have closed the gap. So you need to be able to see because, generally speaking, if a breach does occur, in many cases, the company, the organization will still operate. But you need to work quickly to make sure that that doesn't happen. And privileged access management has now got a role to play because we know that many, many attackers will look at privileged access accounts or people with privileged access as a number one direct route into the organization. And we see that time and time again.
And we need to, with the help of artificial intelligence, particularly, reduce the manual effort in compiling incident data. A lot of we talk to customers at Coppinger Cole. Many buyers of PAM do buy session recording, session management, but they tend quite often to neglect it and only use it when they, you know, when something has happened. And a lot of this is because that type of session recording and traditional session management is quite labor intensive. It means a lot of manual analysis work, some of which is unnecessary.
So we need to streamline all this so that only the really crucial stuff is accessed or recorded, and then that is put through to the investigators. Now, some of the challenges, and this is not just with new emerging PAM, but obviously with PAM in general and PAM as it becomes more sophisticated, there are challenges when deploying that scalability can be hard to achieve, particularly with some older privileged access management, which are perhaps more geared towards on-premise deployment.
We need PAM that is able to integrate in the most modern way possible with legacy systems, but also other modern applications. This often means that we're talking about microservices, we're talking about a platform which is based on Kubernetes or something. But the important thing is that because the dynamics of your infrastructure are changing all the time, the dynamics of the people and machines, then PAM can't stand still. The days of installing PAM because it did this one job are over, okay?
Now, PAM needs to do lots and lots of things all at once, and it is becoming, as I said, a cornerstone. You need to be able to do all this processing. You need to be able to give people and things access as quickly as possible just in time. There's two types of just-in-time. One is literal just-in-time so that identity or whatever it is has never had privilege access before you, but you can make the decision as quickly as possible and give it to it. But there is also some people call it just-in-time where some accounts or identities have a standing privilege, but it's not activated.
So that's not real just-in-time. So which is what we're coming to now, and what Alexander will talk about is pre-execution. We're talking about pre-execution now. So when we say execute, that is the moment when an identity is given access. So the more that we can do before that particular moment happens, the more we can ensure that that identity is getting the right access and they're getting the access to the right stuff.
So quickly, the future of PAM is, I believe, a much greater focus on context-aware and adaptive access control, which is kind of a much neater way of summing up what I've just been saying in the last 10 minutes or so, that we must move away from the static PAM. We must move into something much more flexible. PAM may not even be called PAM in the future. It may just be called access to an extension of identity access management, but it deals specifically with privileged stuff in the cloud or on-premise, et cetera.
Most importantly, I think, is this is an idea that's sort of come around and back again. And I'll show you a diagram in a minute about how this might work. But PAM needs to have a greater alignment with data governance practices and risk management practices, both of which are also being enhanced with artificial intelligence, et cetera. We tended to, like I say, at the moment, we very much focus on the identity and the privilege of the identity and less so on what it's trying to access.
And I think we need to use the two together so that we use much more sophisticated data governance and risk management so that we can say, well, this stuff here is valuable, but this stuff is super valuable. If this gets out, we're in big trouble. This stuff is not so valuable, and this stuff is, you know, it doesn't matter. If you don't do data governance, if you don't do risk management, you have no idea what that is, and you're, like, running around trying to catch up or work these things out.
And that's why privilege access management fails because standing privileges, somehow some data might get put into a bucket, which that privileged account is allowed to access, and suddenly that privileged account is accessing something that no one knows it was there because this is what's happening. So you need advanced tools that can see the shift in the network, can see the shift in the contents of buckets and servers, et cetera. So that's where we're going, and then that's when you can say, oh, hang on a minute, no, this identity shouldn't be going there, and then you stop it, you see.
So then we need to expand these capabilities to support, you know, areas such as DevOps, CAD, CI, which do indeed work in exactly the way I just said, that they are one of the biggest challenges to privilege access because those guys do shift things around. Everything they do dynamically changes almost on an hourly basis.
Therefore, trying to attach traditional PAM to that isn't going to work. That's why PAM is evolving. So my recommendations for organizations, for you guys looking at this, is to, if you're thinking about privilege access, start looking at some of these emerging features that vendors may be offering to future-proof your investments. Balance protection, but also with forensic and compliance needs, which, again, is kind of what I was talking about just now. And look at solutions that integrate with a broader IAM strategy, not a broader IAM product, but a strategy.
A strategy is different, so that could be your framework for your organization, how you actually deal with identity and access across the whole organization. PAM is a crucial, crucial part of that. So that's three main recommendations.
Obviously, there's more. We can tell you much more at Kubernetes. But this is really just to sum up what I've really been talking about.
Right now, we tend to think about identity first. So we take those identity types, the admin, developers, and you. We actually focus on what those identity types, what permissions they have, what allowances they have, what roles are attached to them. And then we think about what they're allowed to look at. We need to perhaps start thinking about the repositories and the data and what all that represents. And then we can use the tools that we have. And I think ITDR is something that we don't want to discuss too much.
But we can use PAM, KIM, and IAM together, but we could use PAM on its own for many organizations that can start doing this process where we look at the data first, we look at what's out there, who's trying to access it, and move to a situation where we no longer just, like, give people standing privileges. We no longer, like, focus on what a developer should have in a kind of abstract, in-the-book way, playbooks.
You know, playbooks will say a developer needs access to this. In the real world, a developer needs access to a lot, lot more. And it changes, as I said, on a daily basis. So we can still have our foundational elements for all of this. So we still have zero trust. Let's not get into that. But data governance is, again, a foundational thing that seems to have been left off the page a little bit, but I think it needs to be brought back in.
And then, of course, there are detection response capabilities as well. So that's really what I have to say. It's now over to Alexandra to give us his view and also a demo. So over to you, Alexandra.
Thank you, Paul. Let me introduce myself once again. My name is Alex. I'm product manager at Siteka. And my focus for today is to walk you through the key functionalities of Siteka PAM, explain how it works, show you the ease of usage, ease of maintenance of the privilege access management functionality provided by Siteka. Let's begin with privilege access management functionality. And Siteka PAM is equipped with a range of features designed to secure and monitor privilege access effectively.
First of all, with privilege account discovery and onboarding, this feature automates the discovery of privilege accounts within your active directory environment and within your local environment, optimizing the onboarding to ensure no account is left unmanaged. After the onboarding process, the privilege, the credentials of privilege account will be securely stored within the encrypted vault and Siteka will protect the sensitive credentials from unauthorized access.
Privilege session management enables a real-time monitoring and recording of privilege sessions, providing full audit trail for compliance, maybe for forensic purposes. And all session data securely stored within your on-prem, cloud, physical, virtual environment, but only your administrators have access to this environment and such data, which is securely stored, has custom data retention policies.
With multi-factor authentication, this feature enhances the security by requiring the time-based one-time password, like additional layer of the verification before granting the access to the privilege accounts. And with role-based access control features, administrators can define and enforce access policies based on roles, ensuring that the user has only necessary permissions to perform their tasks. With the password management, password management forms like a cornerstone of Siteka PAM. And this password management includes, first of all, the workforce password management.
It's a password vault that can help your employees to securely store their credentials, securely store privilege credentials. And most of it, you can securely share those privilege accounts, privilege credentials between your employees. And I think this is the main advantage with securely sharing because it's everything based on my experience. And it was a real situation from my life when I shared the privilege credentials of one of my test environment with one of my colleagues and with just keeping it secret.
And then I just stopped controlling the information, which was shared with my colleague. And this is why the workforce password management was implemented within our corporate environment, where we can securely share the accounts, shared accounts, privilege accounts within the employees without sharing any credentials, like we are the corporate messengers, like Teams, Slack, or something similar. With automated password rotation. So this feature supports both manual and automated changes for Windows, Linux privilege accounts, for Active Directory accounts, and as well for SSH keys.
Because with our SSH key management, you can simplify the secure handling of these SSH keys, ensuring they're not overlooked. And I want to pay attention for the encryption because all data within the PAM module, everything that will be stored within password management functionality will be securely stored on your end and all data will be encrypted by Zytec Unix server certificates. So no one except of you has access to this data. Zytec account discovery capabilities make it simple to identify and manage privilege accounts.
First of all, you can configure the automated scanning of your Active Directory or Windows local system to discover the privilege account. Regarding the Active Directory, you are not limited just with one domain. If you have within your environment, five, 10 Active Directory domains by some purposes, reasons, so you can configure multi-domain rules. And plus you can configure the specific automated schedule for each your rule. And within that centralized task management, you can facilitate the one-click or bulk onboarding of newly discovered accounts.
In addition to this, we have the real-time notification systems that will help you to be updated within the latest newly founded accounts or display the detailed logs about each automated scan. And regarding the detailed audit logs, all manual changes, adjustments to discovery rules, bulk onboarding processes, or any changes within the PEM module will be recorded by Zytec ecosystem and using audit logs, you can review everything that were done within the system. About the privilege access and session management, we have the Jumpbox.
So Zytec Jumpbox functionality offers secure and control access. And this secure and control access will be within your closed isolated environment because the Jumpbox can be as a gateway between external and internal network. And it's mostly used for remote employees, where your remote employees can connect directly to your environment only through this Jump server. And we can cover the secure access for Windows, Linux, Unix, privilege accounts. It can be even Microsoft SQL accounts.
In addition to this, with web-based access, the Zytec can grant access to your employees for any web resources that requires authentication purposes. And with granular control, your administrator can define which endpoints are accessible for specific privilege users. With just-in-time approach, the administrator can provide secrets for specific time frames, minimizing misuse risk. So any changes that will be applied for the privilege accounts will be automatically applied to the systems from where those privilege accounts will be used.
With the password check-in, your administrator can control the concurrent usage of privilege accounts. If it's a shared account, so in this case, the password will be checked in. And it's pretty simple. Who will be the first to be able to use this account? But anyway, all actions will be under controlling and recording by Zytec ecosystem. Using application credentials broker, you can simply get the information about the secret and use the secret without our connection manager. Multi-factor authentication.
Again, it's additional layer of the security that can be configured before your employee will use the privilege credentials, the privilege accounts, and we can be integrated with your active directory or Windows local environment, or you can use Zytec internal users to enable the multi-factor authentication for your environment. So you can be sure that only authorized users have access to your environment and then to the privilege accounts within your environment.
With real-time alerts and incident response, you can configure the rules that will help to protect your environment from unauthorized user actions. For example, usage of forbidden applications, visiting of forbidden websites or some specific scenarios. So first of all, predefined rules, then a real-time response. Whenever the user triggers this specific rule, your system administrator or security administrator will receive an email notification with this specific event that can be reviewed from our platform.
And then, if you configure the automated response for this user, we can prevent usage of these specific applications or, for example, URLs or any specific other scenarios. Thank you for your attention right now and let me proceed with the live demo. I would like to explain you, I hope you can see right now my RDP. I would like to explain you a little small use case from one of our real customers. And regarding this use case, one employee of our customer was fired. I don't know by what reason, but this employee was fired.
But this employee created a sleeping account on one of the servers within the customer environment. And unfortunately, the system administrator doesn't have the audit of all accounts and exactly where this account was created. Using Zyteka, our customer just configured the discovery of the Windows local accounts. And during the configuration, we just defined where we should scan, where we should find these privileged accounts. And after the scan was completed, we find out that this user is not authorized within the system.
So this user has specific privilege permissions, but we don't have audit for this user. Who created it? When it was created? So the first action after detecting of this user was the onboarding process. When you click onboard, you can automatically change the password. So you can rotate the password. And by doing this, you will cut off the access of this account. And this is the first action. After you click onboard, the system will create a secret with this privileged account with already onboarded, sorry, rotated password. Then my customer decided this server has a privileged account.
And maybe, anyway, we cut off the access of this account from any other person, any other employee. But instead of creating a new account for this server, my customer decided to share this account with system administrators, with the employees who requires to maintain this server. So by simplifying this, you can open the secret. And in this permissions, you can define who has access to this privileged credentials, where your trusted employees have access to this privileged credentials.
And in addition to this, you can configure the approval workflow every time, whenever all users with whom you grant this access requires to use this privileged credentials to maintain your server, your infrastructure. Every time such users require approval from you, like from security officer, from system administrator. And only after this, I think I will start the session recording to understand what user will do with this privileged credentials.
And the last part of it, regarding the auditing, we can simply understand what changes was performed to this secret, to this privileged credentials, who used it, when it was used, who changed something. It's not only the administrator's log, it's my playground, where it's only this user. But anyway, if somebody will change something in this case, you will be notified. You will see everything, so no actions will be hidden from your side. I guess that's all from my side. Thank you very much for your attention, for your time.
And Paul, I think we can proceed with Q&A section, Q&A time. Before we get into the questions, though, let's just give you the next poll, which we'll leave up and then do the questions at the same time. So having seen what I said and what Alexander said, what do you think your next step will be today? We're not literally like the next half an hour, but in your kind of future planning, will you explore or implement or think about upgrading your current PAM solution? Conduct a security review of your current privileged access. That might mean you don't have a dedicated solution.
Will you start looking at vendors and start comparing their offerings? A good place to start is the leadership compass from cooking a cold, obviously. And perhaps just tell your colleagues about this and plan some next steps. So let's leave that up.
Alexander, we have, as I said, some specific questions on your product. The first one is, how does SciTech or PAM manage privileged session recording to meet those compliance and auditing requirements that we were talking about? First of all, we have two types of session recording for your privileged accounts. And one of this type can be enabled. So session recording can be enabled only whenever the specific privileged credentials are in use. The system administrator or security officer, he will see only the usage of these credentials.
And with the timestamps, with the index searching, with information about all actions during the usage of these privileged accounts will be recorded and stored within the customer's environment. And the second option that can be configured for the SciTech, this is a session recording from user login to user logout. So everything, all user actions and usage of the privileged credentials, this is a part of user actions that can be recorded by SciTech.
Again, all actions will be with timestamps, with all detailed information about the applications, URLs, user actions, and some additional features that can be configured within the advanced monitoring capabilities. I hope I managed to answer the question. I think you did. Unfortunately, we can't ask the person that asked the question, but hopefully that did. But they can, as can anyone, obviously get in touch with you for more details.
But carrying on, what options does SciTech have for setting up those granular access controls, like restricting access to stuff I mentioned, like specific endpoints or buckets or resources? First of all, within the SciTech platform, we have role-based access control where you can define who exactly can do what and where. For example, System Administrator Alex can maintain and configure PEM module only for Windows Server 2019 and only for some specific users. Then this System Administrator Alex will be able to create secrets with privilege-sensitive credentials.
And after the creation, the System Administrator Alex has owner permissions of the privilege credentials that are stored within the password vault. After it, Administrator Alex can share the privilege credentials, but only the usage of the credentials with employee Paul, with employee David, and with employee Michael. But Michael requires some additional permissions, for example, to maintain the infrastructure and to use these privilege credentials not only on the Windows Server 2019, but also Server 22.
So in this case, Administrator Alex just grants additional access to this user Michael to perform maintaining tasks under privilege accounts within additional servers. Another way how you can perform this, again, with role-based access permissions, you can create a list of allowed endpoints for your employees. They will use privilege credentials.
Again, with password checking, only one user can use the privilege credentials concurrently and only within the allowed list of endpoints. So the user, even with privilege access, will not be able to access any other endpoint within your environment except of allowed list and only under this privilege credentials. The main idea is the user doesn't know the login and the password. When you're sharing, you're securely sharing this. He will not be able to copy and paste to steal the login and password. Everything will be securely stored and encrypted within the password vault.
Okay, talking about password rotation, then, does this include service accounts, which I think I didn't mention, but obviously very important? What capabilities do you have for service account administration? Service accounts can be defined, first of all, as Windows local accounts, or for example, this service account can be part of the Active Directory domain. So in this case, we can automatically or manually rotate the passwords of such accounts. When the password will be rotated, this password will be automatically updated within the Active Directory or Windows local environment.
So you can configure the entity that has permissions to rotate the password of AD, service account, Windows local account. By the way, in addition to this, we can provide the automated password rotation for Unix system, for Linux accounts, even for SSH keys. We can simply change the public SSH key and then put it to the trusted folder within the Linux environment.
So again, handling everything regarding the Linux accounts. And the last part of the password rotation is Microsoft SQL. It's also a part because Microsoft SQL can be used using Windows authentication or SQL authentication. So in this case, we can both rotate Windows and SQL credentials in order to secure the access to these accounts.
OK, well, this is actually a very good question because it kind of sums up the stuff we're talking about. But how can you map dependencies between service accounts and other systems? Which is kind of what I was saying about suddenly something might become connected or become important or it wasn't before. So how do you map those to ensure that a rotating credential does not take down a dependent system? First of all, after the detecting of the service account, it is put into the secure vault and only the authorized user has access to this.
And again, we have this specific unity, which can be defined by, it's like a user who has specific permissions to rotate the password of the service account. And after it, the task or the service account that is used for specific tasks, but can be run manually by the system at the current moment, manually by the system administrator.
OK, and then let's just talk about specifics of password rotation. You know, some people would say that that doesn't necessarily mean that a password is secure. How do you ensure that it's secure within SciTech? First of all, right now we are implementing the password policies that can be configured by your system according to the compliance, according to your security policies that will help you to rotate the passwords, again, according to some rules to prevent easy passwords, to prevent simple passwords that are visible for everybody that is like QWERTY 1, 2, 3, 4, 5, something like that.
I guess at the current moment, this is a major functionality for this, for the password rotation and for the password policies. Because at the current moment, we have predefined policies, but in the nearest future, we are going to add the custom policies that can be configured according to your preferences, according to your security company policies.
OK, just looking at the results of that poll, what will people do after today? And most of the responses were either conduct a security review of their current privileged access or research vendors and compare offerings, which is nice to hear, particularly, as I said, there is a leadership compass out there in which SciTech are also very much part of, so you can research the vendors there and look at what you need.
One thing I always say to people looking at a CognitoCore leadership compass is not just to look at those vendors in the top right or on the far right, et cetera, but look more carefully at all the vendors and read about the vendors individually, because it may be that vendors that are perhaps in the middle or even further down are actually a perfect fit for your business. They might be a perfect fit for a particular application or department, so don't just read it from top right and then leave it at that.
Yes, obviously, some vendors that do have more capabilities, they're bigger, et cetera, doesn't necessarily mean they're right for you. So I would urge you to read that. The leadership compass is still quite new. It was only published, I think, in October.
So, Alexander, if I was to ask you one thing that you would say to a potential customer or a potential buyer, and they didn't really know too much about privilege access, but they knew they needed to implement it, what would be your first kind of tip? Please find something that will be easily maintained, easily deployed, because, again, you need to support this infrastructure. Sometimes solutions can be really different, and you need to combine five or ten, maybe three different vendors, different solutions in different places.
You need to maintain it, you need to support it, and the tip is to find the easy way to solve your issues, to solve your headache with the access management, with identity management, and with the control of your infrastructure. Okay, I can't, I don't, I think I missed the first poll. Did I actually display the results, Alexander? I don't think I did.
No, no, no, you displayed the second probably. Okay, so working backwards, the first one, then the majority of people said the answer was A, that the most critical feature is granular access controls with role-based policies, so that's good. Next was seamless integration with existing IT systems, which, again, is kind of what you might expect.
And then, finally, real-time risk assessment and action blocking. Interestingly, no one chose advanced audit and reporting capabilities, which I think perhaps is a bit disappointing, because I think that is something, maybe we should have rephrased it a bit so it's not audit and reporting, but more about governance, but anyway, those are the responses. Let me just see if there's any more questions coming in from outside. Not so far.
So, Alexander, I think we probably can wrap this up, unless there's anything else that you would like to add? No, it's pretty well. Thank you for your time today. Thank you for the invitation.
Well, thanks for being here. It's been great. As you can see, if you do have further questions, you can email me directly at Kupinga Cole. You can actually send me inquiries that you might want me to forward to Alexandra or to Saiteka. Very happy to take those on.
And also, even if you have some questions about your particular privilege access management challenges, I'd love to hear those as well. But for now, I will say thanks to Alexandra. I'll say thanks also to my producer, who is working very hard there in the background. And I will say thank you also for watching today. And as I said earlier, this will be available to download later on our website. But for now, have a safe and a wonderful day. Bye. Bye.
