Remote workers and weak machine identities: a dangerous mix

Remote workers and weak machine identities: a dangerous mix

Michael Thelander of Venafi explains the risks that insecure machine identities pose to a remote workforce, and how to manage them.

Now is the time to ensure safe remote SSH access.

The coronavirus pandemic has drastically changed how businesses operate. In a move to protect employees and try to limit the spread of the disease, the crisis has seen most organisations across the world implementing a work from home policy. As result, the use of Secure Shell (SSH) machine identities, otherwise known as SSH keys, is on the up.

SSH keys are used to provide identity and access management capabilities to network administrators, allowing them to manage systems and applications remotely, log in to another computer over a network, execute commands, and move files from one computer to another.

Now, with hundreds of thousands of people working remotely during the pandemic, attackers are looking to steal and exploit SSH machine identities. Why? Because they are extremely valuable – they provide remote access to some of the most critical systems and data in the world.

In light of this, organisations need to maintain visibility and control over all of their SSH machine identities to ensure safe remote SSH access.

Why are SSH machine identities so important?

SSH machine identities are ubiquitous; present in every datacentre in the world, half of the world’s web servers, and practically every Mac, Unix or Linux computer, whether on-premise or in the cloud. With 50 to 200 SSH machine identities per server, organisations may have upwards of a million SSH machine identities.

The sheer quantity of machine identities being deployed makes effective management difficult. Yet, cracking just one SSH machine identity enables attackers to pivot to other systems and explore an enterprise’s entire network, until they find the one systems that offers up the most lucrative data.

The risks from poorly managed SSH keys

In the wrong hands, poorly managed SSH machine identities can be used to circumvent security controls, enable privileged access to networks and data, move laterally through systems undetected, and insert backdoors into networks.

Depending on the sophistication level of the attack and attacker, this can continue for days or even months, with huge ramifications for companies. Trickbot is one such malware; it first appeared as a banking trojan in 2016 and evolved to steal SSH keys by 2019, compromising more than 250 million email accounts in the process.

Risks around SSH machine identities are exacerbated by SSH key sprawl. The average organisation may have ten to even fifty times the number of SSH machine identities than it is aware of. This number is so high because of physical and virtual machine growth and the explosion of cloud infrastructures that rely heavily on SSH keys for remote access.

In addition, SSH-based machine identities do not expire and most organisations never change them. Key sprawl is further compounded by orphaned machine identities (authorised keys without a corresponding identity key). Many of these SSH machine identities are long dormant and often forgotten by administrators, providing an easy point of attack for hackers, and enabling them to impersonate admins and obtain complete control of target systems.

SSH cyber-security best practices

With hundreds of thousands of people now working from home and requiring safe remote SSH access, it is especially important organisations maintain best practices. The following four steps are essential for protecting SSH machine identities and ensuring safe remote SSH access.

  1. Monitoring: It is critical to constantly monitor SSH machine identities to maintain insight into when and where keys are generated, and by whom. This helps to assess SSH security risk by determining who is using what SSH machine identity and how they are being used.
  2. Eliminate unused or orphaned keys: To help eliminate key sprawl, any SSH machine identity that has been out of use for a certain length of time (a typical period would be around 90 days) should be removed, as should keys without corresponding identity keys.
  3. Rotate: Rotation is a critical part of cybersecurity defence and reduces the risk of SSH machine identities being misused. During challenging times, such as we’re experiencing today, SSH machine identities should be rotated on a higher frequency than normal. This should happen weekly for “root” or highly privileged keys, and monthly for all others. It is also important to bear in mind that even in modestly complex environments, an automated method is required: manual SSH key rotation is unfeasible for most organisations.
  4. Report: As with any part of the IT infrastructure, SSH usage should be regularly reported on. Building a set of metrics and sharing them with peers in risk or security departments helps create the mindset and incentive required to construct stronger SSH policies.

Michael Thelander is director of Director of Machine Identity Strategy at Venafi, a role he has held for over two years. His primary role is to help educate people about machine identity management and cybersecurity. Michael has more than 20 years’ experience across various brand from raw startups to mature market leaders.





Copyright Lyonsdown Limited 2021

Top Articles

RockYou2021 data leak: 8.4 billion passwords compromised

A report shows that 100GB of data which includes 8.4 billion passwords have been recently leaked on the internet, people are being encouraged to secure their accounts.

Hackers Breach Electronic Arts & Steal Game Code

Electronic Arts, one of the world's biggest video game publishers including games such as FIFA, Madden, Sims and Medal of Honor, are the latest company to be hacked.

JBS Foods paid £7.7m in ransom to REvil ransomware gang

JBS Foods, the world’s largest processor of beef and poultry products, has admitted to paying a ransom of $11 million to cyber criminals, a week after it announced that operations…

Related Articles

[s2Member-Login login_redirect=”” /]