Welcome!

Matthew McKenna

Subscribe to Matthew McKenna: eMailAlertsEmail Alerts
Get Matthew McKenna via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Article

SSH User Keys Now a C-Suite Issue | @CloudExpo #Cloud #BigData #Security

SSH is a reliable means of providing remote access securely for administrators and vendors

Why SSH User Keys Are Now a C-Suite Issue

With so much on their plates, most C-level executives don't have the bandwidth to think about SSH user keys. It would be much simpler to leave such details to the IT department - but that would be a mistake. Why? Because SSH means access - to an organization's servers and data. The creation of SSH user keys is not a controlled process, which means that someone can create credentials without oversight. That fact should be enough to get the C-suite's attention.

SSH is a reliable means of providing remote access securely for administrators and vendors and securely moving your data, in many cases, from point A to point B. SSH has been in your organization for the last 15 years, doing its job quietly and efficiently behind the scenes. It comes pre-installed at an operating system level on all Unix and Linux variants. It sits on 60 percent of the world's Web servers. It is the primary means of accessing and providing maintenance to servers as well as to your network devices, your routers, switches and firewalls - all the things that keep your business running.

Who's Holding the Keys?
It may seem strange - and even reckless - that such a powerful protocol has never been controlled. But there are several reasons for this. For one thing, in the majority of companies today, SSH is not centrally owned or governed by a particular group within the business. It has historically sat in the underworld of Unix administrators and local application owners for the last decade. Access has been provisioned on an ad hoc basis. Administrators are not bad guys; they are tasked with keeping your systems up and running in the middle of the night.  They want to do their jobs quickly and efficiently.

A second reason is that, until the release of the NIST-IR 7966, "the best practices on interactive and automated access for SSH key-based access," there was no authoritative guidance on the topic. The major consulting houses are just starting to develop practices to help advise their customers on how to approach and manage the risk.

And third, this form of access has not been something that identity access management teams have seen in their remit to control. SSH keys are slowly but surely finding their way into projects related to privileged access management but are mostly being looked at from the perspective of "flesh and blood" users of the keys. Unfortunately, upwards of 80 percent of the SSH-related access is for machine-to-machine connections.  On the other side of the coin, cryptography teams have only been asked to look at certificates and encryption keys.  SSH user keys have traditionally not been in their remit, either.

The SSH protocol is not well understood among executives, even those at global corporations, so they are not aware that it is one of the largest uncontrolled access risks to their businesses.  As they become educated about SSH, they raise a very logical question, "I have never heard of a breach related to SSH or SSH user keys - why should I do something about this now?"

The answer to that question is another question: How could you know if you've had an SSH-based breach? The majority of companies today do not have inventories of the SSH user keys their administrators have created over the years.  These key-based credentials are not monitored. You don't know where they are being used from, how frequently or why. You are not able to associate them back to owners in your environment.  The fact is, you wouldn't know if a malicious actor had access to SSH user keys in your environment. You wouldn't know if they were misusing this encryption to exfiltrate data out of your organizations.  In essence, it is the perfect attack vector for malicious actors.

SSH user keys provide unlimited access to an organization's trading systems, payment processing systems, databases where credit card information or patient data is kept, routers and switches which keep information flowing efficiently, file transfer systems which move that data. Imagine uncontrolled access to everything that keeps your business up and running. This is not only a question of risk and compliance; it is a question of resilience.

This Could Be You
Imagine: Your organization has just hired a contractor who is going to help with some IT-related work. They are put through an approval process with the human resource team and approved by the business owners whom they will work for. You onboard them into your identity access management system. They are provisioned a user name and password, given a computer and are able to begin their work.

As the contractor gets to work, he or she begins to provision SSH user keys and gain access to test machines and maybe even leave some keys behind on production machines.  Then their contracting period comes to an end. They are removed from your identity access management systems, their user name and passwords are revoked, their computer collected.  A job well done. The system worked. Unfortunately, it didn't. You forgot to revoke their key-based access. And unfortunately, you can't because you never tracked or controlled the provisioning of this critical access. The contractor who has just left your organization still has access!

Taking Control of Your Keys
Organizations can't afford to treat SSH user key-based access lightly, hoping that upper-level executives or auditors don't find out about it. To give a sense of the size of the issue: in a banking environment with 30,000 Unix/Linux servers, one can expect to find up to 4.5 million SSH user keys for application-to-application connections and 450,000 SSH user keys for system administrator- or database administrator-related access. That's 4.5 million potential points of access to your most critical systems that you don't have a strong degree of control over.

With an understanding of how critical SSH keys are, you need to learn from those tasked with encryption, infrastructure and access management. Find out where responsibility lies for controlling SSH user key-based access in your organization, as well as for provisioning and de-provisioning such access. Is there an access control policy in place, and can you enforce it? Getting clear answers to these questions will help you secure access to your organization's treasure chest of data.

More Stories By Matthew McKenna

Matthew McKenna is Chief Strategy Officer and vice president of Key Accounts at SSH Communications Security. He brings over 15 years of high technology sales, marketing and management experience to SSH Communications Security and drives strategy, key account sales and evangelism. His expertise in strategically delivering technology solutions that anticipate the marketplace has helped the company become a market leader.

Prior to joining the company, Matthew served as a member of the executive management team of ADP Dealer Services Nordic and Automaster Oy, where he was responsible for international channel operations and manufacturer relations. In addition, he was responsible for key accounts including Mercedes Benz, General Motors, and Scania CV. Before this, he played professional soccer in Germany and Finland.

Matthew holds a Bachelor of Arts degree in German from the University of South Carolina and an MBA from the Helsinki School of Economics and Business Administration.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.