Well, good morning, ladies and gentlemen, welcome to another cooking, a call webinar. This is our first webinar after long summer break of almost two months. I hope you have all enjoyed the great summer weather, but now unfortunately it's over and let's get back to work. The topic for our today's webinar is you thought shadow. It was bad. Well, meet your company, shadows, administrators, or how like infrastructure management might turn the ubiquitous security tool into a ticking time bomb. My name is Alexei Belski. I am a lead Analyst at call and I am joined today by har Yaki lion, who is a white president for enterprise key management and our SSH communication security company. This webinar is supported by SSH communication security.
Well, before we begin, just a couple of words or of who we are, what Ko Nicole does in case you don't know about us yet, we are an Analyst company based in Germany, and yet geographical distributed all around the world. From the us to Australia, we are providing enterprise research advisory and division support for all areas of information security. Or of course we are besides the research services and advisory projects, we are doing quite a lot of events ranging from free webinars like this one to really big conferences where our headliner event is of course the European identity conference, which will take place next may in Munich, which will be our 11th year. And you are definitely all welcome because we rightfully consider EIC the biggest IM and it security related event in Europe or another relatively new topic for us would be digital finance technology. And we are hosting for the first time and event on the topic or next March. So you are very welcome. And please find more information about our seminars, webinars and those events on our website.
Some short guidelines for the webinar. You are all muted centrally, so you don't have to worry about that. Or we will do a recording of this webinar and we will publish the webcast on our websites latest tomorrow. We'll also send all attendees and email with link. Please ask your questions. Anytime during the webinar, you can use the questions tool in the web, go to webinar control panel. It probably be in the right bottom screen of, sorry, right? Bottom corner of your screen. Again, please submit the questions. As soon as you have them, we will pick them up, enter the webinar, and I will read them aloud during the Q and a session.
The agenda is very simple. First, I will introduce today's topic a little bit and give you an overview of what kind of security and compliance tricks, your SSH keys. And you do have a lot of SSH keys in the, even if you don't know it yet, what kind of those security you may be facing? And then I will switch to Carline and we will go a little bit deeper on those issues. And of course, introduce the companies possible solution for those problems. And at the end, we will have the Q a session again, please submit the questions. As soon as you have them, I would like to begin in a traditional way by showing this screen, you know, we are now living in an increasingly interconnected world, everything, and everyone is connected and it's not just people. It's not just your companies, employers anymore. It's everything. It's companies, business partner, suppliers, or customers are the current and potential ones. It's all those connected vehicles, smart watches. I, the IOTs in internet of things, all those mobile devices, everything communicates or the amount of digital assets is growing exponentially. The data can be anywhere and the data has to be securely moved around and securely accessed from anywhere at any time.
Of course, this increasing interconnectedness gives you a lot of new business opportunities, brings you a lot of exciting technologies, but of course it also opens up all new ways of exposing Euro data to security risks. And one of the topics which I actually put into the title of the webinar is shadow it just to give you a quick recap. And we have quite a lot of publications and past webinars on this topic shadow. It is when or your employees are kind of growing tired of waiting for the it department to provide them with appropriate modern digital tools with cloud services or social networks or any other tools out there. And they take taken home the all he, and they start using our those tools without central oversight, which means that it loads, visibility and control over the corporate data. Those data can be easily compromised, cause a lot of privacy and compliance conflicts, basically a shadow it problem is huge.
And there is a lot of talk about it in the price and whole new product markets I merge or to address it like those cloud access, security brokers, enterprise mobility managers, et cetera. Cetera, it's estimated that over 60% of companies are affected so great shadow. It is clear, but what about the shadows admin should administrators? Well, what if I told you that there is a problem which affects hundred percent of all the companies out there and the risks include uncontrolled, some prevention of your existing IM controls, non-existent identity, lifecycle management, nearly complete lack of feasibility in government or the problem that that actually brings a compliance nightmare because it directly violates all major compliance regulations. It exposes your system for external and internal threats. And yet somehow, almost nobody is talking about it. Why and how can you guess the course? Yes, of course. Or it also appears our webinars title slide.
It's SSH, it's a secure show or keys, which are all everywhere out there. And somehow people just don't talk about them. You know, the famous pony Institute has done this way last year and they discovered that over 75% of companies just don't care about SSH. They just let individuals, hopefully administrators, but not really all the time, just manage their SSH keys individually. And over half of those companies simply do not have any visibility or governance over their existing SSH keys. And yet somehow it does not cause the uproar in the press. Interesting. First of all, I guess we have to say few words. What actually what SSH actually is, well simply put according to Wikipedia, secure show or SSH is a cryptographic network protocol for operating network. So it's a securely over and unsecured network sounds good. It has been originally designed in Finland in the 1995 by one totally alone, who incidentally went on to establish a company called SSH communication security.
And now is the company CEO. What an amazing coincidence. The second major version has been designed by ETF and adopted 2006. It's based on public key. Cryptography provides several layers of protocols, which take care of things like network encryption compression, key exchange, multiple methods of strong authentication or not so strong, whatever you choose. And a lot of convenience services built on top of that basic protocol. It's open sourced, it's extensible, it's ubiquitous. It has really become a defactor standard for remote access to network systems, servers, mainframes, you name it. And it's commonly used for multiple other purposes like secure file transfers, device management, process automation, application deployment. And so on. Many people would of course know, PKI the public key infrastructures, or either from those magic or lock icon in browsers, which indicates that the connection to the website is encrypted. But of course they are more often used in large enterprises for stronger authentication, you know, all those smart cards and other types of hardware or software based strong authentication methods.
The major differences between PKI and SSH are highlighted on this slide. They're both based on public cryptography. They both provide encryption onion. They both based on some kind of digital keys, but there is one major difference or PKI is by definition and infrastructure it's has a central authority, which manages those keys of certificates. And FSH does not FSH is inherently several yeah, authority less. I would say anyone can generate those keys. And the bigger problem is that those keys do not contain any metadata by just looking at the key. You can never tell what's the purpose who made note that key when this key is supposed to be expired or was the key somehow compromised and revoked as opposed to X 5, 5, 4, 9 certificate where this information is built into it, you can never know. So PKI is are important. They are used by large enterprises, mostly because they cumbersome throw out and manage.
SSH has nothing to manage. They're very easy to start working with. So they are everywhere. And by saying everywhere are really minute because, or you are definitely using SSH keys, even if you don't know it yet. Now here, I just highlighted some areas where those keys are used. Basically they used on all existing platforms from Unix, like servers to windows, machines, and Mac and mainframes, and even Euro iOS and Android phones can work with the stage. At least clients, those servers are built into every notable network device. And of course in most of those IOTs smart things out there they're used for all types of administration like remote show, comment, execution, process automation, application deployment, they used for all types of services, which need traffic encryption secure file transfer, data, sharing, backup synchronization, remote storage, accessing your corporate resources from out there, you know, VPN like manner.
There are actually VPN solutions based on SSH. And of course, by connect for connecting your cloud infrastructures to your company's networks. And there is a lot of different identities involved from administrators, which are actually entitled to access critical systems to some service accounts, built into network devices, applications, many standard users can and will use SSH just to simplify their daily work. And of course there is a lot of those rogue orphan and lost and compromised and hacked and stolen identities, which align somewhere around. And since you don't have a central infrastructure to manage them, you just don't know. In fact, can you guess, how many of those SSH keys SSH based identities you actually have lined around your corporate network? I did the very short test. I've taken my own laptop, which is my private one. It no way connected to any domain or enterprise network.
And they found that it contains over 60 SSH keys. Some of them, of course, mine, legitimate ones. I used to connect to my Amazon cloud account, my applications, some of those came with some business apps, which I have installed and some are simply unknown. I have no idea where those keys came from and I have no way to find out because there is no metadata in there in a fairly large enterprise. You can have easily hundreds of thousands, even millions of keys. I guess car will be talking about that statistics later in more detail. Anyway, FSH is everywhere and SSH is great. It's very easy to deploy here. We actually have the same situation like our, those restful APIs.
If you know, restful APIs are easy to use, they have no built in security. Any beginner application to open can start using them in five minutes. And this is what they did. All those carefully crafted enterprise specification like soap. They never get, they never got enough traction and everyone is using recipes. And now we have to build new infrastructure around them to actually solve those problems. And here on this slide, I have listed major risks of SSH keys, the first and the biggest one that you actually have no control over, who is creating new SSH keys around your network. Since there is no central authority, anyone generate those keys. You're just only this tiny program for that. And you can deploy them anywhere and immediately you have access to some critical system. There is no visibility into a key purpose or validity. As I mentioned, those keys have no metadata. So just by looking at a unknown key, you cannot actually say where it's used. You have to find out, at least the other end, the public key, the public part of the key deployed on the system somewhere.
There is very limited means to identify unauthorized on and orphaned keys. I mentioned, if you stumble upon a key, if you stumble upon a key, which you may very well not in months and years, unless you have a specialized tool for key discovery. But even if you find one, you have no idea where it came from. What the hacker was it? One of your employees, what some contractor dismissed years ago, you never know. There are no legitimate means to revoke compromised key with those digital certificates. For example, you just can issue a revocation record and or systems all will know that they should no longer trust a particular certificate with key. The only way is to remove the actual physical key that of course can break your legitimate business process somewhere, which is relying on that key. Or I mentioned that uncontrolled proliferation of those keys or which anyone can create and then unknownly mix and deploy somewhere instead of a real one.
Basically you can get an immediate access or an SSH encrypt tunnel to a critical system. And you will have difficulties to, to even realize that there is a complete second dimension going on of your existing controls. And of course, end, it's also compliance nightmare because most our compliance regulations nowadays have explicit clause covering key management. And you might well what well say, but yeah, we actually do key management. We have a great enterprise key management products installed in our network with the third wide encryption models and stuff. Yes, you probably do. And great, but that's still not enough because those key management tools usually manage those only those keys, which are known to you. And if they, the key are known, it's still line out somewhere out there and not in your hardware security module, you might actually very well say you already have some privileged access management tools deployed for your administrators to ensure that your admins actually are always tracked. What exactly are they doing on which critical system? Again, that's absolutely great and the systems belong to every sensible or enterprise infrastructure. But again, the only cover those keys and systems, which you already know should be covered.
So unless you have a very specialized software tools for coming through all your infrastructure services, network devices, IOTs, mobile systems, and stuff like that, and finding out and checking our cataloging at each key and somehow discovering its purpose, and then continuing to monitor the Schutze keys. You're basically only seeing a tip of your iceberg and remaining completely unaware, but that big underwater part until it hits you. And unfortunately, ignorance is not ABL in this case because yeah, sooner or later, and rather sooner you'll probably be hit with either a data breach or a compliance fine, but yet there is some light into the tunnel. And today we are actually going to talk about solutions to address this problem. And this is where I would like to hand over to from the SSH communication security company to talk about this solution in detail,
Thank you Alexei for the very, very good overview of the SSH secure shell and the risk landscape. So for the part of these today's webinar, we are focusing a, a bit more on the actual findings of our customer assessments and then also going into the best practices and recommendations of how we see enterprises are taking these things under control and what we can offer to help you to get there.
After the webinar, there will be a brief survey sent to all the participants. One of the questions is that we decide of your Linux and UX environment, as Alexei mentioned to DEO standard on Linux and environment, also ons and windows, but very pervasive on the Linux and units environment. So this is just kinda to get you a bit of thinking that how big of my environment or could be. And once we go into the actual findings of the environment, it kind of gives you a better understanding of how big the problem may on your specific environment. So let's jump into the statistics from real customer deployment.
As Alexei mentioned, the SSH keys are actually an metric key pair consisting of a private key and an authorized key, meaning the public part of the key pair. What we see on our customer assessments in average is that for every thousand units servers general, there are roughly 10, 10 keys per server, meaning that for every thousand machines you can expect to find close to a 10,000 private keys. These private keys are the users, identities that users are using to prove their ID whenever they are connecting to the server. And basically use that as part of their user authentication procedure, let's take the public key side of things. So basically what is the public key that grants and authorize these, the user to access the server for every thousand servers, we are seeing roughly hundred thousand authorized keys, meaning hundred thousand dollars access credentials in the critical infrastructure. That's roughly hundred keys per server.
Okay. Then if we go into the trusts that are basically the formation of the private key and the authorized key, we're seeing that on every thousand machines, there is roughly 1,500 trusts trust relationships that are unknown to the organization and are actually granting a highly privileged access to the infrastructure. So this is maybe the most scariest thing. It doesn't really matter how many keys or credentials you have, but in average, on our customer assessments, we are seeing that there are a significant amount of access, credentials, SSH keys that are granting access to a highly privileged account, such your account out of which 90% are not even used anymore for real purposes. But those are just there because there hasn't been any governance procedures or monitoring in place to actually get those removed.
Kind of getting back to the survey question of the size of the environment and the findings of 10 private keys per server hundred authorizations per server, and like 1.5 or so, couple of ed accounts, unknown, privileged access credentials into the environment. What does this actually make in your environment? What we're seeing on the customer assessments? Probably it is something like this. So these are the three most common, let's say policy violations that we are seeing on our customer assessments. The first one is that as the keys are used ex extensively for the automated processes and provisioned by the users, by themselves, very many customers, let's say all the customers are dealing with unmanageable mesh of trusts. So the diagram shows the, the trust between the machines and over time, this has grown into a problem that you can't really figure out who's connecting where using what kind of keys, more precisely to the policy violations.
There are a couple of things that are very much highlighted on every PC. I DSF monetarial authority of Singapore, two, three ISO 27,000. And so standards is that users are using SSH keys to bypass their existing security controls. One of the very common way is that customers, they do have their jump server infrastructures, where they channel the users and then enforce key stroke logging or similar capabilities to monitor the usage of, of the sessions. But what we're seeing on our assessments is that there are lots and lots of stage key based access that the users are using bypass. These controls. Another very common policy violation is the segregation of duties. So for acute security practice, the development should be separated and isolated from the production machines. However, what we're seeing on our customer assessments like here on the diagram, you can see the production there on the middle as a green.
And then on the left hand side, you can see those blue boxes, blue circles that are basically development, user acceptance, test quality assurance, and so forth. And as you can see, there is a lot of cross connectivity between the production and non-production, these are maybe the three things that we're seeing mostly on our customer environments that are clear policy violations and the risk factors let's jump to the real world. Real world example for seconds. This is the, the study is based on one of our customer assessments we did for a major international back. The challenge was that there was a, a production outage that caused a root cause analysis. And eventually they realized that there are lots of SSH keys and SSH access that they are not aware of where the source of the connection is. So basically unknown connection into a production environment.
Auditors advised that the existence of these UN managed authentication systems was a violation of compliance mandates. In this specific case, was Aion of ley even more concerning when digging deeper into the findings was the size and scope of the problem that represented an existential threat to the organization itself, unknown access to the critical trading platforms. It is a significant operational and business risk following up the business risk. Basically it means that the compromise of just one key granting the highly privileged access food access to the server infrastructure would actually expose the bank to the information staff tampering and loss of data. And of course, the related backups as well, and the operation staff were tasked by the CSO organization to bring all the SSH keys and SSH access under full control.
Following up the statistics were find in average, on our customer assessments on this specific case, the environment size was roughly 15,000 Unix and Linux machines. So we are talking a global financial institution here. We found over 200,000 user accounts that had SSH keys with roughly 2 million keys in the environment. This is the one of the cases where roughly 10% of the keys were originating from unknown source and they granted root or other elevated privileges. So a significant risk that you have a significant amount of access credentials granting privileged access to the critical infrastructure, and you don't know where the connections can be made from, and who is in the position of the private keys. Another significant finding was that only 4% of the keys were actually in active use. This highlights the problem that it has grown over the years. And very few keys are actually in active use, but there is still a significant amount of key material in the environment granting possible access, but that shouldn't be there anymore and should be removed from the environment.
The customer also had a significant segregation of duties violation. So roughly half of the connections in production were actually originating from unknown source or from other non-production servers. Another interesting data point is that the SSA user keys that we are talking here today, those were mainly driven by application to application machine, to machine processes. These SSH user keys were used for authentication purposes, more than any other type of authentication, except the end customer log to the online services. So that kind of a highlights, the pervasiveness of the SSH user keys as an access credentials, it basically surpassed easily the amount of passwords amount of clear barrels amount of other authentication methods, except of course the end customer logins to their online.
So how can we help at SSH communications security to get things under control? We see SSH key management being very much a process driven approach that basically you need to start from the beginning, do the assessment part of of it. So basically try to find out what do you actually wanna achieve? What are the policies that you wanna comply with? And then what are the risks and the requirements as part of your project? The second stage is that we discover the environment. We go out there, we pull the information of all your users and all your keys. And based on that information, we are able to provide a trust map. We're able to tell you that these users are using these keys and they are able to access these servers using these credentials. So having basically a full map of trusts now, combining the early defined policies and the current situation, you are able to identify how big the Delta is from the current state, into the desired state. And then we can take the path forward to actually help you get things under control.
The third stage of the process is to monitor the infrastructure. As I mentioned earlier, only a fraction of the keys are actually used in the environment. And therefore monitoring of the environment is very crucial for the success of the project. Typical monitoring period is anything between three to 12 months. We monitor the environment to identify if there are any shared keys and more importantly, what, which one of the keys are used and what kind of keys are obsolete and no longer used and shall be removed from the environment. The monitoring also includes the monitor continuous monitoring of the whole environment. So if user manually goes behind the scenes of the tool and creates a new key pair, provisions, new access to himself, as we continuously monitor the environment, we are able to alert and notify on all these let's say unmanaged changes, and we are able to push the policies back in place.
So you are not only able to get your environment in a pretty good shape, but you can also make sure that people are enforced to use the tool. And they're no longer able to bypass the security controls after the monitoring period, when you basically know what needs to be done, then we kick off we mediation process remediation means that we basically clean up the environment. We rotate the whole keys. We do, basically whatever is required by the policies to get your environment from where it was into the policy defined state and being compliant with the PCI MAs and so forth. And after the environment has been cleaned up and you are all set, then we automate the full lifecycle management of the key SSH keys. So there is no longer need for any users to create the key keys by themselves, but the tool takes care of the full lifecycle automation, including new key provisioning, key removals, key rotations, everything part of the automation piece is also the integration.
So we integrate key manager into customers, existing infrastructures, whether that is a ServiceNow kind of ITSM tools, whether it's Oracle SalePoint force, rock IBM tools and so forth. So integration to the existing customers, identity and security services is one of the key key factors for a streamlined automation, couple of things to focus on. And what are the key points we kind of already touched part of this. There are the segregation of duties, keys to bypass jump servers, but let's say the significant portion of the key material that we find on our customer assessments is actually the unused obsolete keys and trusts. And that is something that over time over the monitoring that will basically help you to get rid of most of the unused key material in the environment together with our customers. We've built this, the risk versus reward mapping, where you can kind of like try to focus on the higher risk areas, with least impact the operations, and then basically start the project from there and then move towards the lesser risk, but higher risk of higher operational risk areas.
So this is kind of the mapping that we've worked together with our customers to help other, other new customers, to focus their efforts on the right to get their things under control, very overview to, to the SSH platform. So on top of the universal SSH key manager, that is our key management product. We also offer a couple of other additional products as part of our platform. The D SSH is the one that we kind of originate from. That's our commercial client server for enterprise customers. We do have the universal SSH key manager. That is the tool that I kind of just described the process driven approach, get things and SSH keys under control and fully automated. We do have a crypto order product that is our tool for ed access management. So being able to record the sessions, the users are doing, being able to efficiently use shared accounts while still approving the individual accountability of the users and so forth. The unique differentiator for the crypto order is that we can do the auditing session, recording, monitoring capabilities, completely transparent to the end users and processes. So the introduction of the solution into the environment has very little impact to the operations and there's no user training or anything like that required. Another benefit of us of course, is that we are the subject matter experts of SSH. So we have a high class services and consulting for the SSA to related topics, SSH remediation, services, assessment services, and so forth.
The, the key custom benefits that we provide with our solution platform is that, of course, as I mentioned, the unique knowledge and submental expertise around the topic to begin with, but also our solution is based on a three customer benefit pillars, whatever we do at SSH, we want our solutions to reduce the risk of our customers, operational and business risk. We want to reduce the operational cost and we want to increase the efficiency of our customers. And not only that, we also want our customers to do better business in the future. So we see the whole cloud enablement and transformation, dynamic access control, and getting from after the fact prevention into, from after the fact analysis into a preventative mode, clearly these kind of a business enablement business, distinct com competence and, and these factors of any companies to succeed in their business in the future. So resolving the problems of today and providing a path into a more secure future.
Before we jump into the questions and answers of this webinar, there is a, a as part of our solution portfolio, we do have a hell check service and a hell check probing tool that is a small, lightweight service for our customers to get started. One of the challenges we see on the market space is that a lot of the customers, they do realize that yes, we use SSH extensively on our environment, but we don't really see what we don't really understand the possible impact and the magnitude, the size of the problem we may have. Therefore, as part of our solution portfolio, we do have a small, tiny scanning tool and health check service to get our customers a immediate feedback, immediate report into the, into their environment to take the path forward into the, possibly into the commercial tools of hours or some alternatives. Now, as an offer for all the webinar attendees, we offer the scanning tool free of charge for all the attendees.
The tool is basically very lightweight scanning. It doesn't impact any production environment, so it can be easily run on the production environment. And it provides you a summary statistic report of pssh softwares. You have configurations and more important keys you have on your environment to kind of make the first initial assessments of how the environment looks like. The second stage is an optional, small, very cost efficient, lightweight service that we basically take that information and we provide a more thorough analysis and findings recommendations based on, based on the data. So basically it includes a bit of an interview and a much more comprehensive report of the findings analysis, including all the risks and possible impacts mapping into the most com common compliance, mandates, and regulations. And then of course, recommendations, risk based recommendations into how things, how to get things under control. And then of course, we also do have a commercial product universal such key manager that can be used to resolve the problem if seemed necessary.
The second question on the survey that we will be sending you after the webinar is to basically to probe probe your interest for the free scanning tool that is now available for the webinar attendees. So whenever you get the survey, it will be highly appreciated to let us know if you are interested of the free scanning tool or for the health check service, so that we can help you, help you to get things started. At this point, I would like to thank you for your time to join the webinar. I hope you found the information useful for your business, and if you have any, any, any quest, further questions, feel free to use the questions and answers questions box on the webinar, and we'll take your questions in a bit.
So we are now ready for, for the Q and a session, but before we begin just one short note from myself as an Analyst Analyst. So I actually find this opportunity to, for free SSH health check, really great. And I would definitely, I mean, without actually endorsing any specific products, which we are not allowed to do as Analyst, but you should definitely go for this type of health check, even if you honestly believe that you are not affected by the public. Cause you will definitely be unpleasantly surprised by the results of such a health check. So go for it. I would definitely recommend one. And by the way, speaking on behalf of the future viewers of this webinar as a recording, are there any other ways to actually come back to you and ask for such a health check for those people who somehow missed the webinar?
Yes. So basically there are ways to get in, in touch with us. So of course through our website, there is a contact us forms that where you can request for the hell check and we'll take it from there.
Okay, great. So as for, for the questions, please keep them coming. We already have quite a list, or, and of course we have quite a few questions specifically about the product, but let's begin with the more generic ones. And I have a very interesting almost existential list. One, let me read it out for you. Doesn't switch into smart cards, help enough already, at least you'll know all your keys and fingerprints and revocation and audit procedures are communication is out of scope, but for user keys, it really helps. So what, how would you reply to that statement?
Yeah, thanks for the question. I think it's a very, very good question. Valid question. Moving into smart cards. It definitely helps on the interactive users. So basically human users who log into their, let's say workstations using smart cards, they can use the PKI, or they can use Kerber authentication to access the, the servers for, for the interactive sessions for remote operations and file transfers of the, let's say human flesh and blood users. The challenge here is that smart cards are not really that usable for the application to application and machine, to machine connectivity on our customer assessments. We see that the interactive usage is merely the tip of the iceberg. So we see that maybe 10 to 20% of the identities and remote access is actually interactive. Whereas the remaining 80 to 90% are actually machine to machine application to application connectivity. And this is basically where the SSH, the plain SSH keys are extremely widely used. So it's, it's kind of, I'm not fully replacing it. I think the PKI and smart cards and are, are very much complimenting the usage of the SSH keys. So each one of those has their, like let's say sweet spot, that there are, are very valuable tools to be used with.
And if I may add a couple of words from a Analyst perspective, first of all, I would actually stop using the word smart cards. Cause you know, smart cards themselves are already almost, I think, of the past and many companies having a lot of problems rolling out the smart card infrastructure because well, by far too many devices have no smart card interfaces at all, both mobile devices and even modern laptops. And of course smart cards are limited to internal employees. Mostly it's not scalable to internet size or deployments. So I would actually start talking about adaptive and stronger integration in general, which will definitely be growing in the future, which will definitely be much more flexible and multifaceted and much broader range of different integration types than just smart cards. But as you already mentioned, this is a very different area with the quite a small overlap. So just definitely you have to, to think about your ation strategy for users, but you also have to remember that you still have this huge legacy burden of those, which aren't really going anywhere. Okay. Next question. I guess it's relating to, to your bank example, aside from root generic accounts, were admins using locally defined accounts or LUP or other integrations
Okay. On the, on this specific bank or let's say it's, it's more of a generic statement. I, we are seeing a combination of everything. So we see that certain accounts are local, of course, privileged accounts, such as roots, maybe DBA, Oracle and some application accounts. Those are typically local. Whereas the end user accounts are typically tied into an active directory or a N N plus or an LDAP for the key repositories. We see a lot of keys that are stored on the local file systems, but we see also a lot of keys where the users have NFS home directories. And that of course magnitudes the problem to, to a certain degree because on held up and NFS scenarios, the of users time, the machines get easily very high and complicated. So on this specific case, they use local and niche accounts. But I would say that large enterprises, we see the whole spectrum of local directory accounts, local and NFS keys.
Okay. I guess from this question, we could kind of transition to another one. So can you maybe describe a little bit more details how the universal SSH manager can be integrated with other existing solutions? Like for example, active directory or the other things in place you mentioned?
Sure. So there is a native integration into an active directory. So we're able to pull all the accounts and information from the active directory right away for the, let's say the other most common integration points are integration into a service management tools. I mentioned ServiceNow as example, being the market leader in the space. And the other integration point is the identity managers, let's say Oracle and sale point as an example, the product itself, it has a graphical user interface for interactive processing, but it has a full rest API and command line interfaces for the integration. So basically all the functionalities are available through the rest interface, as well as through the command line. So basically it can be integrated into let's say a third party reporting, third party, identity management, third party. It, it service management provisioning, configuration tools and so forth. So it uses a standardized interfaces to basically connect to wherever you need to be connected with.
Okay, great. And by the way, another point, what I mentioned before rest API rest APIs are extremely insecure, but they are very easy to use and deploy. So everyone is using rest it's I guess it's the same applies to SSH. So yeah. Smart cards are great, but they're very difficult to manage, so you'll still have to deal with SSH. Okay. Next question. What about the use of blockchain for machine to machine authentication? Oh, that's a really great one. I wish I could get 1 cent for every time someone mentions blockchain because I will be a billionaire, I guess already. So do you have anything to say so typical blockchain?
Sure. Yeah. So I mean like this is, this is kind of like the whole, like what we talk about the business enablement as one of the benefits is that there are two different problems, or let's say some of the analysts are calling this like a bimodal bimodal. It, that you have your existing production processes and your existing enterprise environments that you need to maintain and so forth to keep the business running. And then you have this leading edge DevOps cloud kind of areas where you kind of really wanna push forward is streamlining and efficiency. How we see the world is that right now the enterprise environments, they have a significant risk on the existing enterprise environments where SSH keys are ex extremely widely used. So the first stage is to identify the magnitude of that risk and then get that under control only after you've actually taken that under control.
Then you can convert the known factors, the known access into a more modern ways of dealing with things. For example, putting all the access credentials into a centralized world using key, less access, like for example, Netflix is doing, or then using blockchain as an authentication alternative authentication method. So how we see the world is that you have your existing problems that you need to resolve to order to increase the efficiency and reduce the risk, and then us providing a path into the current infrastructure into a more modern future. But yes, blockchain is it's a hot topic and can be used for a various purposes machine to machine authentication being one of the,
Yeah, I guess blockchain is now that probable hammer, which everyone is running around with and seeing all problems as nails. I guess there will be a lot of interesting areas of application blockchains in the future, but we are not there yet in any case. Okay, great. Next question. UKM can detect alternative trust because it sees all configurations and keys on all nodes, but how to prevent their use can such itself be configured to prevent bunny hopping.
Yes. So there are certain ways that you can actually prevent the, the hopping or we call those transitive trusts. So basically hopping from one server to another, using keys, to hop to another hop to another hop to another, until you find yourself, find your way into the crown jewels. There are certain restrictions that you can put in the keys. So keys can only be used from a certain locations. And more importantly, on the, on the server configuration side, on the key configuration side, there is a configuration restriction that you can basically put on any key that the key is, can be the key can be restricted into a specific purpose only. So if you have a database backup key, you can configure that key to be valid only for database backup. This means that even if the key is compromised, or if someone tries to use the key for any other purpose, such as opening up a terminal and basically hopping using that to hop from one server to another, it just doesn't work. Another, another area is to where you can restrict the usage of the keys and prevent the hopping is to leverage our, let's say crypto order product as an example, where you can force users to go through a single point and then configure the servers to allow connections only from that single point. So that basically prevents you from helping from one server to another, by restricting that where the connections can be made from.
Do I understand you correctly that basically you have some, at least some other privileged access management functionality integrated in your tool. Cause this is what it sounds like. Yes.
So as part of yes, yes. Correct. So part of our solution portfolio, we do have the crypto order product that is a privileged access management functionality of in a transparent fashion. So that is one thing that you can fairly easily and efficiently, effectively use to prevent that kind of a leapfrogging bunny hopping, transit trust scenario. That was part of the question.
And again, I guess it's another point towards the statement that this whole SSH environment problem just spans across multiple functional areas, which people usually consider separated ones like strong authentication or privilege management or secure function. It all spans all those areas and this is why it's so difficult to manage. Okay, next question are more practical ones, which platforms does your product support?
Okay. Basically our solution supports all the various Linux windows IBM's. So you can have any unique flavors. We support the most common Linux implementations. So that from the platform perspective, also windows and IBMs at OS, we are planning to introduce support also for the network devices sometime during next year, from the SSH implementations perspective, we support a wide variety of SSH clients and servers. Of course, our own, of course, we also support open SSH. That is the, the factor standard on Unix and Linux. We support device, we support SSH quest, SSH and, and so forth. So there is a attach made SSH. So we try to cover the, let's say the, of course, the open source community, but also the most common commercial implementations of SSH. And of course this is always across all the supported platforms.
Do you have some kind of agent which has to be deployed on those systems? Or how does it work?
There are a couple of different approaches. So one of our, let's say the easiest way to get started is to leverage the agent less connectivity. So all the management operations can be done purely agentless on Unix and Linux infrastructure. We leverage the existing SSH server running on the target servers on windows. You need to deploy an agent. And of course the environment can be hybrid that you can basically deploy agents to some degree. Then you can leverage agent less for the rest of the infrastructure. The new feature of the trust release version is to leverage an external scanning. So if the customer has chef multiple puppet blade logic, any kind of provisioning tool, the scanning operation can be done using those third party tools. And you can just import all the information into a key manager. So that's kind of a very fast way to get started and get full visibility into a key manager without actually a proper attachment of the tool itself.
Okay, great. That's the next question one. How does transitioning to the cloud affect the use of SSH and SSH keys?
That's a very, that's a very good question. And we get that from our customers a lot. So I mean, everybody, all the customers, they are heavily getting into cloud. They're thinking of their cloud strategies. They are putting into their private and, and, and public cloud hybrid clouds and they are moving their workloads into the cloud environments, the nature of the virtualized and cloud environment. It's much more dynamic, right? So the challenge with this is that you may spin off couple hundred machines or a thousand machines for duration of some hours or days or weeks. Key manager can be attached into the existing provisioning process. So whenever basically you spin off these machines, those are automatically attached into a key manager and you can provision the keys into those machines basically as part of the provisioning process. One of the things that I mentioned as part of the business enablement is that we are also looking for paths to actually provide a more cloud native SSH access management paths, for example, putting everything into a centralized repository instead of local keys and so forth. So we do have a couple of customers that are running key manager on, let's say Amazon, Amazon EC two computing. And from the key manager perspective, it doesn't really matter if it's a cloud or if it's on premise. It's part of the provisioning process anyways.
Okay. Sounds really good. And unfortunately we have just reached the top of the hour. So I guess we do not have much time left for, for the questions, but of course you can always just go to ssh.com and or contact communication security in any possible way and asks the questions directly there. And of course you can always apply for that free SSH health check there also please visit our website, copy a call.com. And here are some related research documents we have published, including the review of the product itself. Thanks a lot for attending our webinar. And I hope to see you again into some of our future webinars. Thanks a lot to KA and have a nice day. Bye.
Thanks for your time. Bye.
