
Sign up to save your podcasts
Or
In this podcast I speak to Matthew McKenna, COO and EVP of SSH Communications who have launched their SSH Risk Assessor Security product at Infosecurity Europe this year. They talk us through the product and explain some of the other elements around SSH security.
For related articles and podcasts visit http://www.itproportal.com
Firstly give us some of the background on SSH?
SSH are the inventors of the SSH protocol. The SSH protocol has been used for remote log on for Unix admins for a long period of time. However it is also a very well known method of secure file transfer. The company has evolved itself over the last year or two and in terms of moving more closely into the identity access space. In particular, we see that a lot of our customers are having challenges in managing the complexities around their environment. This goes into the areas of access control, auditing SSH usage, how we manage host keys in the environment and a very hot topic, which we are touching upon with our customers is how SSH user keys are managed in the environment to date.
So, explain what we mean by Secure Shell Environments?
As mentioned earlier, secure shell is primarily used by remote administrators for remote logging in to Unix environments. That is one use case that we have. The other use case is secure file transfer. This is machine to machine connectivity and data transfer from machine to machine. When we look at environments today we see that SSH probation is everywhere it comes pre-installed in all Unix and Linux environments it is basically to a large degree on all web servers and it is essentially the plumbing of the most critical infrastructure inside the network environment of organisations and it is where the most critical data of organisations is running through quite often.
What are your typical clients?
I would say those organisations which say have the greatest risk to date in terms of their key management but SSH is used everywhere and we see it widely used in financial organisations and widely used in government and in the retail space. If you think of any transaction that comes from a front pointed sale system, that data has to be transferred to a back end server somewhere and that is quite often being transferred through SSH. We see this machine to machine file transfer as making up 90% of automated file transfers within the automated access environment.
Quite vulnerable data then what sort of risks threaten these kinds of environments?
I think the challenges that organisations are facing around managing their SSH user access has been that historically there have been no processes in place to manage the SSH user key operatives. So we see in most environments that admins have had the possibility to set up the user keys on an ad hoc basis and there has been no inventory kept. Basically, you end up with the situation where potentially that admin leaves the organisation at some point and they still have their keys because there has not been a process in place to have the ability to easily remove these keys when an administrator leaves the organisation. The same goes for automated file transfers. We see very often see a situation where an administrator comes into a development environment and does the work there and everything works fine. They then implement this into the production environment instead of going out and coming back in through the production set up. What they will often do is use SSH and some of the nice things that SSH and tunnel into the production environment directly from a development environment and set up their own key pairs there. Now, they can work in the production environment and after that leave but that key pair allowing access from the non production environment to the production environment is actually left in place. This is of tremendous risk to organisations where these key pairs are left for years on years and you basically have the possibility of un-vetted access. Over time, these key pairs add up and you are basically left with a very complex mesh in the environment of trust relationships that are becoming more and more difficult to match.
So, the key is quick detection and quick assessment. Does your tool help clients make decisions on what action to take?
Exactly. What we are trying to do is give our customers a potential path to remediating their SSH environment. I think for any customer to have the possibility to do this, they first need to know what the size of the issue is in their environment. What SSH has done is build a very light weight risk assessment tool for our customers which is easy to employ in their environment to give them visibility as to the size of the issue.
You mention the various layers of compliance, can you explain more on what compliance measures are met?
We see if you take PCI as an example you see a lack of connection between authentication and access management so we see a lot of phraseology around the need to rotate your passwords, you need to have passwords of a certain length. Now we see the movement in the direction that will also have this type of language related to user keys as well. If you think about it in terms of what we mentioned earlier, keys are actually making up a much higher percentage of the authentication from machine to machine. So these are starting to get the same level of visibility as user name and password within the cloud standards and if you take a look across such compliance as CCI you do get to see more and more visibility coming in to SSH access management user keys. Of particular interest is some of the work we have doing together with the ITS standards board around SSH access management and access user key management.
Are you seeing out in the industry and in your market place increased interest in these kind of threats?
Absolutely, we are seeing a wide interest especially in the financial sector and the government sectors around this topic because it has been a very nasty secret for a long time meaning that the administrator has had the visibility of this for some time. They often say that at the end of the day it is not their responsibility to remediate this issue so it has been definitely an education process bringing this more to the light of the organisations out there.
What threats are you seeing as the biggest problems in the future?
I think the biggest issue is that people who have the most privileged access in the environment are usually already on the inside of the organisation and it is more about how to build better processing standards to manage access on a need to have access type of basis. In particular what we see is how do we create that delineation and segregation inside critical environments between non production and production type of host. We see a great trend moving to the cloud we see a lot of outsourcing where third party vendors will come in and they will be able to do work on a customer’s production server and testing environments. These people from the outside also set up key pairs. How do we monitor how those keys are being used when they come into the environment and how do we have the ability to remove those when that outsource provider is no longer needed? It's about getting visibility of who has access to what and when on a need basis.
In this podcast I speak to Matthew McKenna, COO and EVP of SSH Communications who have launched their SSH Risk Assessor Security product at Infosecurity Europe this year. They talk us through the product and explain some of the other elements around SSH security.
For related articles and podcasts visit http://www.itproportal.com
Firstly give us some of the background on SSH?
SSH are the inventors of the SSH protocol. The SSH protocol has been used for remote log on for Unix admins for a long period of time. However it is also a very well known method of secure file transfer. The company has evolved itself over the last year or two and in terms of moving more closely into the identity access space. In particular, we see that a lot of our customers are having challenges in managing the complexities around their environment. This goes into the areas of access control, auditing SSH usage, how we manage host keys in the environment and a very hot topic, which we are touching upon with our customers is how SSH user keys are managed in the environment to date.
So, explain what we mean by Secure Shell Environments?
As mentioned earlier, secure shell is primarily used by remote administrators for remote logging in to Unix environments. That is one use case that we have. The other use case is secure file transfer. This is machine to machine connectivity and data transfer from machine to machine. When we look at environments today we see that SSH probation is everywhere it comes pre-installed in all Unix and Linux environments it is basically to a large degree on all web servers and it is essentially the plumbing of the most critical infrastructure inside the network environment of organisations and it is where the most critical data of organisations is running through quite often.
What are your typical clients?
I would say those organisations which say have the greatest risk to date in terms of their key management but SSH is used everywhere and we see it widely used in financial organisations and widely used in government and in the retail space. If you think of any transaction that comes from a front pointed sale system, that data has to be transferred to a back end server somewhere and that is quite often being transferred through SSH. We see this machine to machine file transfer as making up 90% of automated file transfers within the automated access environment.
Quite vulnerable data then what sort of risks threaten these kinds of environments?
I think the challenges that organisations are facing around managing their SSH user access has been that historically there have been no processes in place to manage the SSH user key operatives. So we see in most environments that admins have had the possibility to set up the user keys on an ad hoc basis and there has been no inventory kept. Basically, you end up with the situation where potentially that admin leaves the organisation at some point and they still have their keys because there has not been a process in place to have the ability to easily remove these keys when an administrator leaves the organisation. The same goes for automated file transfers. We see very often see a situation where an administrator comes into a development environment and does the work there and everything works fine. They then implement this into the production environment instead of going out and coming back in through the production set up. What they will often do is use SSH and some of the nice things that SSH and tunnel into the production environment directly from a development environment and set up their own key pairs there. Now, they can work in the production environment and after that leave but that key pair allowing access from the non production environment to the production environment is actually left in place. This is of tremendous risk to organisations where these key pairs are left for years on years and you basically have the possibility of un-vetted access. Over time, these key pairs add up and you are basically left with a very complex mesh in the environment of trust relationships that are becoming more and more difficult to match.
So, the key is quick detection and quick assessment. Does your tool help clients make decisions on what action to take?
Exactly. What we are trying to do is give our customers a potential path to remediating their SSH environment. I think for any customer to have the possibility to do this, they first need to know what the size of the issue is in their environment. What SSH has done is build a very light weight risk assessment tool for our customers which is easy to employ in their environment to give them visibility as to the size of the issue.
You mention the various layers of compliance, can you explain more on what compliance measures are met?
We see if you take PCI as an example you see a lack of connection between authentication and access management so we see a lot of phraseology around the need to rotate your passwords, you need to have passwords of a certain length. Now we see the movement in the direction that will also have this type of language related to user keys as well. If you think about it in terms of what we mentioned earlier, keys are actually making up a much higher percentage of the authentication from machine to machine. So these are starting to get the same level of visibility as user name and password within the cloud standards and if you take a look across such compliance as CCI you do get to see more and more visibility coming in to SSH access management user keys. Of particular interest is some of the work we have doing together with the ITS standards board around SSH access management and access user key management.
Are you seeing out in the industry and in your market place increased interest in these kind of threats?
Absolutely, we are seeing a wide interest especially in the financial sector and the government sectors around this topic because it has been a very nasty secret for a long time meaning that the administrator has had the visibility of this for some time. They often say that at the end of the day it is not their responsibility to remediate this issue so it has been definitely an education process bringing this more to the light of the organisations out there.
What threats are you seeing as the biggest problems in the future?
I think the biggest issue is that people who have the most privileged access in the environment are usually already on the inside of the organisation and it is more about how to build better processing standards to manage access on a need to have access type of basis. In particular what we see is how do we create that delineation and segregation inside critical environments between non production and production type of host. We see a great trend moving to the cloud we see a lot of outsourcing where third party vendors will come in and they will be able to do work on a customer’s production server and testing environments. These people from the outside also set up key pairs. How do we monitor how those keys are being used when they come into the environment and how do we have the ability to remove those when that outsource provider is no longer needed? It's about getting visibility of who has access to what and when on a need basis.