Privileged credentials — keys to the IT kingdom

Cyberark Software (Australia) Pty

By Sam Ghebranious, ANZ Regional Director, CyberArk
Thursday, 24 March, 2016


Privileged credentials — keys to the IT kingdom

Organisations often overlook protection of their privileged SSH keys, thus leaving a gaping hole in their defences.

Privileged accounts provide direct, all-powerful access to an organisation’s most critical systems and sensitive data. If compromised, they can provide external attackers and malicious insiders with unfettered access to the heart of the enterprise. This makes the security of privileged accounts a critical concern for any organisation, yet many businesses have no idea exactly how many privileged accounts exist within their organisation, nor do they know how many credentials provide access to these powerful accounts.

When organisations think about credentials, they typically think of passwords. Yet, that’s too narrow a definition. When thinking about privileged account credentials, organisations must consider both passwords and Secure Shell (SSH) keys.

The role of the secure shell

The SSH protocol is widely used throughout traditional and virtual data centre environments. It is used to authenticate users and applications to remote, internal Unix and Linux systems and encrypt the resulting session traffic. Successful authentication requires a user or application to present its private SSH key file to a target system that possesses the corresponding public SSH key file. Once the key pair is validated, the user or application is granted access to the protected system.

In a one-to-many environment, in which one private SSH key is used to obtain privileged access to many target systems, this kind of arrangement significantly increases security risk.

An unseen risk

The problem with SSH keys is that they are often easy to create but very difficult to track, manage or control. Unlike Active Directory (AD) credentials or digital certificates, SSH keys can be generated without any involvement by a third-party authority that ensures trust or verifies access rights.

In an unmanaged environment, any user with access to any Unix or Linux system can generate an SSH key pair that will forever grant that user direct access to the system. And, because there is no built-in oversight for SSH keys, security and administrative teams may never know if and where potential backdoors exist.

Further, because SSH keys are commonly used in automated application-to-application authentication, SSH keys are often hard-coded into application scripts and never thought of again. This leaves applications and application servers potentially vulnerable to attacks using compromised, unsecured SSH keys.

In an enterprise environment, where the IT team may be dealing with hundreds of users and thousands of systems, SSH key security challenges can become exponential. A large enterprise may have thousands or even millions of valid SSH key pairs, many of which may no longer be needed by authorised users or applications.

The cost of doing nothing

As organisations strengthen security measures in other areas of the network, attackers are pivoting to easier targets, and this has brought SSH keys within their sights. Research from the Ponemon Institute shows that within the past two years, 51% of organisations have been affected by an SSH key-related compromise.

As compromises increase, enterprises that continue to leave these privileged credentials vulnerable will face increased risks of data breaches and failed audits. To strengthen security, protect sensitive data and comply with industry policies and regulations, it is essential to integrate SSH keys into an organisation’s overall privileged account security strategy.

Where to start?

One the greatest challenges associated with the SSH protocol is that key pairs can be created at any time, by anyone and on almost any machine. Worse, they never expire. According to research by IDC, the average large enterprise that has been using SSH keys for more than 10 years and has more than 10,000 servers is likely to have more than one million SSH keys in its environment. Of these, many are obsolete or belong to users who have since left the organisation.

The first step in taking control is to understand the scope of the issue. Organisations should use a technology solution that can scan their environment to identify and locate all SSH keys, document the age of existing keys, map relationships between users and systems, and determine which keys are within or outside of organisational policies. With this knowledge, it becomes possible to create an action plan.

Proactive controls

When left unmanaged, SSH keys are stored as system files that can easily be moved or copied. To avoid the resulting risk of key theft or unauthorised sharing, SSH keys should be removed from vulnerable endpoints and systems, and instead stored in a highly secure, central repository that supports access controls such as automated workflows for elevated-privilege requests and strong authentication.

Once organisations understand the scope of SSH keys in their environments, the next step is to centralise and secure private user and application SSH keys.

Proactive key rotation is another essential element of SSH security. Organisations should rotate all SSH key pairs at regular intervals, just as they would rotate privileged passwords. Though this is difficult when key statuses and locations are unknown, when user and application SSH keys are consolidated under one central management system, key pairs can be automatically rotated and public keys can be automatically distributed to target systems without burdening the IT team.

Develop a response capability

To complement these protective measures, organisations should ensure equally strong detection and response capabilities. To minimise potential damage from internal or external attackers, organisations should institute monitoring for all privileged sessions, including those that occur via SSH. When abnormal activity is detected, security teams should have the ability to remotely terminate the suspicious session to disrupt the potential attack.

Similarly, all privileged session activity should be recorded. When an incident is detected, response teams will benefit from immediate access to session recordings and detailed audit logs to determine exactly what happened and what steps must be taken to resolve the incident. Access to these privileged session recordings and audit logs can also be granted to auditors to help prove compliance with regulations.

Threat analytics can also play an important role in understanding threats. Consider introducing behavioural analytics tools to shine a light on privileged account activity. By analysing the use of privileged accounts, passwords and SSH keys, behavioural-based algorithms can learn what’s ‘normal’ for each user and system and, as a result, quickly detect when an activity falls outside of that norm.

In the battle to protect sensitive data, privileged account security is a critical line of defence. Too often, organisations fail to protect their privileged SSH keys, thus leaving a gaping hole in their defences. To mitigate the risks posed by uncontrolled, unsecured SSH keys and eliminate permanent backdoors into critical assets, it is imperative to create a plan to secure, manage and monitor these privileged credentials just like any other.

Related Articles

The AI regulation debate in Australia: navigating risks and rewards

To remain competitive in the world economy, Australia needs to find a way to safely use AI systems.

Strategies for navigating Java vulnerabilities

Java remains a robust and widely adopted platform for enterprise applications, but staying ahead...

Not all cyber risk is created equal

The key to mitigating cyber exposure lies in preventing breaches before they happen.


  • All content Copyright © 2024 Westwick-Farrow Pty Ltd