the technical complexities and risks of public key authentication

7/29/2019 The Technical Complexities and Risks of Public Key Authentication

1/10

The Technical Complexities and Risks of Public Key Authentication:The Lack of SSH User Key Management in Large Enterprises Today

A User Key Management White Paper


2/10

TABLE OF CONTENTS:

Abstract and Executive Summary......................................................1

Security Risks Related to Public Key Authentication...........................2Universal SSH User Key Manager and Risk Reduction......................5Conclusion..........................................................................................7


About SSH Communications Security:

Founded in 1995, SSH Communications Security is the company that invented the SSH protocol- the gold standard protocol for data-in-transit security solutions. Today, over 3,000 customersacross the globe, including 7 of the Fortune 10, trust our Information Integrity Platform to securethe path to their information assets. Our platform enables businesses of all types and sizes toprotect their information assets by providing the gold standard data-in-transit security solutionsthat prevents data loss in both internal and external environments, hardened perimeter securitythrough our multi-channel two-factor authentication and internal security control managementsolutions that enables organizations to more easily manage user keys and monitor administratortrafc across your networks

2012 SSH Communications Security


3/10

Abstract:

SSH (Secure Shell) is a protocol and software suite for securely transmitting les and databetween computers, point-to-point tunneling of sensitive data, and securely administeringremote computers. Developed in 1995, by Tatu Ylnen, It is now an IETF (Internet EngineeringTask Force) standard and is available in many commercial and open source avors.Implementations of the SSH protocol are available on practically all platforms, from IBMmainframes to Unix, Linux, and Windows servers as well as routers, embedded systems andsmart phones.

To automate application-to-application data transfers, it is the industry best practice to use whatis known as public key authentication in the SSH protocol. In public key authentication, a digitalsignature key pair (consisting of a private key and public key) is created, which after thedistribution of the public key is used to prove the identity of the user or application accountsduring the SSH authentication process. Additionally, many organizations also use it for grantingtheir system administrators access to computers that they manage. These key pairs used foruser authentication in SSH are called user keys.

The challenges faced today by large enterprises in managing SSH user keys include manualtime consuming and error prone process for creating new keys and trust-relationships, , lackof processes, visibility and tools for removal of keys, possibility to copy and misuse the, and nooverall visibility as to which user accounts has the possibility to access what SSH servers andservices. These drivers affect organizations from not only in terms of risk, however also from acompliance and cost perspective.

This white paper focuses on the existing technical risks related to public key authentication andthe lack of SSH user key management in enterprises. It will highlight the architecture of SSHCommunications Universal SSH User Key Manager, address internal security risks inthe architecture, and identify how they have been solved or mitigated. In doing this, it willdemonstrate how the solution can affectively decrease risks faced by enterprises today inmanaging their SSH user keys.


1

Executive Summary:

The SSH protocol is the industry standard for administering large heterogeneousenvironments and secure le transfers. SSH Servers are in many cases housing andtransporting an enterprises most crucial business data and applications, touchingcustomer data, invoicing information, credit card data, patient data, etc... The largest globalenterprises may have in many cases up to a hundred thousand servers running the SSHprotocol in their environment. These may in turn run thousands of individual applications,and over the years thousands if not hundreds of thousands of automated data transfersbetween different applications and user accounts have been set up.


4/10

2

Few enterprises have a structured and automated approach to managing SSH user keys.The security risks around public key authentication increase an enterprises operational costand risk exposure. Additionally, compliance initiative such as PCI-DSS, SOX and HIPAA alladdress the requirements for secure key management. The combination of these drivers inmany cases indicate several million dollars annually in operational cost, risk exposure andcompliance nes related lack of suf cient SSH user key management.

1. Security Risks Related to Public Key Authentication

1.1 Administrators who have left years ago that still have access to critical SSH Servers

Most large enterprises never systematically remove trust relations. This is primarily due to costreasons and to the fact that most organizations do not have documentation or a database of alltrust relationships that they have in place or the purposes for which they were created, and dontknow whether the original need for setting them up still exists.

Public key authentication depends on possession of a private key. Even though technically it ispossible to restrict the IP address from which a login using a particular public key is permittedand the commands that may be executing using such pubic key login, in practice these arerarely used due to the complexity of setting them up manually and the rigidity towards changesin the infrastructure that they create.

If an administrator leaves the organization, there is no way of knowing whether the administratorhas copied private keys to his personal storage or to where the key has access to. When anadministrator creates a key pair for an automated le transfer or other password-less login, theadministrator can easily take a copy of the private key le. That le then continues to provideaccess to the user accounts/servers for which it has been con gured as an authorized key, evenif the administrator is let go, the administrators personal account is closed, or the original privatekey le is destroyed, as long as the public keys remain authorized on the servers.

1.2 Unused User Keys Still Granting Access to Critical Hosts

Having unused trust relations still enabled in the environment increases the risk of rogueadministrators having copies of keys that are still valid. They also make it more likely that accessto one account can be propagated to another account (the trust relationships provided by publickey authentication are transitive). Furthermore, they clutter the overall environment and makemanagement and analysis of active relationships and the whole key management process moredifcult, costly and error-prone.



5/10

3The Technical Complexities and Risks of Public Key Authentication:The Lack of SSH User Key Management in Large Enterprises Today

1.3 Unauthorized Copies of Private Keys

Any administrator who has access to a user account is technically able to make a copy of anyprivate key stored in that account. This is not restricted to users that actually set up the publickey authentication relationship; any user who ever thereafter can log into the client account (oraccess backups containing its les or monitor the network through which such backups wereever made without encryption) may in principle have made a copy of the private key. Suchcopies are just as effective for public key authentication as the original keys, as long as thepublic keys remain authorized on the servers.

1.4 Lack of Key Rotation

Renewing the key pairs used for public key authentication (e.g. changing the keys) is currentlytoo dif cult and costly in practice. As a result, many of the private keys in the environmentare years old and hundreds of administrators, contractors and consultants may have had theopportunity to make a copy of the private key, making it virtually impossible to track down.

1.5 Lack of visibility who has access to what and breakdown of segregation

Currently, most organizations do not have visibility into what machines their administratorsactually can access when public key authentications (transitively) are taken into account.Administrators are typically given access to a subset of the organizations production machines.However, normally there would be automated le transfers and other application-to-applicationconnections from the computers in this subset to other servers in the production environment.

Effectively, the public key authentication used for such application-to-application connectionsescalates the administrators access from just the computers in his/her designated subset toalso those accounts accessible using public key authentication from any account he/she hasaccess to (and any account on a server where he/she has root access, including access throughpublic key authentication, transitively, though his may be somewhat mitigated by special toolsused for controlling and auditing privileged access).

1.6 Lack of visibility of trust relationships crossing production boundaries

Many organizations have policies stating that le transfers or application-to-applicationconnections should not occur between their production networks and development/test

networks. While such constraints can be enforced usingrewalls, sometimes connectionsneed to be allowed for certain controlled transfers. However, rewalls do not have visibility

to the user accounts used within encrypted sessions. Thus, once a connection between twomachines across such a rewall has been enabled, it is at least possible to add other public keyauthorizations between such machines for other accounts and keys. The rewall also cannotcontrol what operations are performed in such connections, because it cannot see insidethe encryption. In organizations that dont have strict rewalls separating development andproduction, there is generally no visibility to whether there are trust relationships crossing theboundary.


6/10


1.7 Lack of visibility of trust relationships crossing organizational boundaries

Many enterprises outsource some or all of their IT to external service providers and consultants.Often the outsourcing provider administers the organizations servers and thus has access to itsproduction network from its premises. Such administrative access is usually implemented usingthe SSH protocol. Many of these enterprises lack visibility as to whether trust relationships forpasswordless authentication exist between the organizations internal network and the serviceprovider. Unauthorized trust relationships to a service provider can expose the organizationto rogue service providers personnel and even highly systematic data leaks. Such trustrelationships might have been established years ago (possibly using a penetration attack).Unfortunately, in many cases the people who set up the initial trust relationships have since leftthe organization. Nonetheless, in many cases the unauthorized automated transfers are stilloperating.

1.8 Inability to audit existing trust relationships

Lack of visibility to existing user authentication keys also means that it is not possible to auditthem. For most organizations, it is currently not possible to audit the following:

Private keys are regularly renewed No private key is ever reused (e.g. with a different passphrase instead of

actually changing the key) No private key has existed longer than a maximum permitted period Who really has access to a particular data, account, host, or application when

transitive public key authentication trust relationships are taken into account Who can actually create new application accounts and change their privileges(given keybased access to some administrative accounts)

Development engineers cannot access the production environment People who are no longer with the company are not able to log in to any of the

computers (even if they can gain a connection to the network or get someoneinside to do the accessing)

Access to systems is properly adjusted when a person changes to a differentrole in the organization

No unauthorized data transfers exist No unauthorized password-less trust relationships exist between an enterprise

and its outsourcing partners.

1.9 The quantity of individuals who can create permanent trust relationships

When trust relationships are set up manually by individual administrators, there is often nocontrol over what trust relationships are set up and whether they are properly documentedand approved. This implies that it is practically impossible to ever remove them. Also, largeenterprises may have hundreds of administrators - this is a very large number of people(especially over 15 years taking personnel turnover into account) and the more people are


7/10


able to create new trust relationships. With the increase of administrators churning through theorganization over the years, the risk increases that any potential policy will eventually not befollowed. Having numerous individuals who have the ability to set up trust relationships is in itselfa signi cant security risk.

1.10 Human errors in manual key setup and removal process

Setting up a password-less trust relationship involves creating a key pair by copying thegenerated public key to all server machines with which the connection can be made (sometimesthousands of them), editing the SSH server con guration le on each server to which the keyis authorized (adding the public key as an authorized key), editing the client con guration leto add the private key as an identity key, ensuring that privileges of public and private keysare properly set, and testing that the setup works This process can easily take from fteenminutes to many hours, and becomes substantially more complicated if disaster recovery sites,replicated/fault-tolerant systems, or load sharing clusters are involved.

Possible human errors during the key setup process include:

Accidentally deleting other identity keys or authorized keys from thecon guration le (possible impact: system outage for some unrelatedapplication)

Copying wrong public key (possible impact: someone gets unauthorizedaccess)

Copying to wrong host or account (possible impact: unintended accessauthorization, possibly to root account on a server if user name forgotten fromcopy destination)

Forgetting to copy (and test) to some server (e.g., disaster recovery server)(possible impact: outage when the backup systems should go online)

2. Universal SSH Key Manager and Risk Reduction

The Universal SSH Key Manager addresses the challenges related to user keys through threedistinct phases. The rst phase of the process is to discover what private and public keys exist inthe environment in their current state and to which users, service accounts or applications they

are related to. The main purpose of this phase is to gain visibility to the existing environment andbeing able to nd out who is able to access where and what is the overall status of the SSH userkey environment. The second phase of the process after the discovery is to take a snapshot ofthe environment and enforce the key management functions to all new key setups, increasingthe ef ciency and control through automated key setups, and identifying and mitigating the risksof the existing environment by analyzing the discovery ndings, organizing the users, keys andother data to groups and start enforcing the trust-relationship policies to the existing alreadyrunning environment. For example, it may be desirable that a group such a SAP users only beable to access the SAP servers in the organization, or that a group of Unix administrators onlybe able to access those Unix servers they are assigned to manage.


8/10

Once the organization of the environment is achieved it is possible then to manage the wholeexisting user key infrastructure in terms of automating private and public key deployments andrenewals, and ensuring key removals when individuals, service accounts or application IDsare taken out of the AD or LDAP. The combined bene ts of achieving a managed environmentinclude cost reduction from the elimination of manual processes related to key setups andremovals, the mitigation of risk through accountability of what private and public keys mayaccess which hosts, and nally compliance in terms of sound key management practices withfull key rotation and removals. Although many of the solutions included in the solution will touchupon signi cant cost reduction or compliance, it is actually the risk mitigation that is the highestpriority of larger enterprises. The table below will focus on each of the challenges presented inpart 1 and will discuss how each of each of the challenges in resolved with the SSH User KeyManager.

Driver Solution1.1 Administrators who have left years agothat still have access to critical SSH Servers

Scan the managed environment, usersand authentication keys, and discoverand identify which user accounts areable to access which of the servers

1.2 Unused User Keys Still Granting Accessto Critical Hosts

Integrate to existing directory sourcesand use up-to-date information to revoketrust-relationships that are no longervalid.

1.3 Unauthorized Copies of Private Keys Identify multiple instances of the keyswithin the environment and enforcerestrictions and access policies to restrict

and lock down the private key use.1.4 Lack of Key Rotation Enable automated private and public key

renewal processes per de ned policies1.5 Lack of visibility who has access to whatand breakdown of segregation

1.6 Lack of visibility of trust relationshipscrossing production boundaries

1.7 Lack of visibility of trust relationshipscrossing organizational boundaries

1.8 Inability to audit existing trustrelationships

Discover and report the user accountstrust relationships, who is able to accesswhere using which of the user accounts.

1.9 The quantity of individuals who cancreatepermanent trust relationships

Enforce the creation of key setups andtrustrelationships through Key Manager.All the manually created keys can beautomatically noticed, revoked andinformed.

1.10 Human errors in manual key setup andremoval process

Key Manager can automate the wholeentire key creation and managementprocess minimizing the manual work andchange for mistakes.



9/10

Architecturally, the key manager design permits enterprises to solve the above mentioned risksrelated to key management in a minimally invasive manner by leveraging existing infrastructureand process. Some of the key components include:

Within the discovery of the key environment, the SSH Universal Key Managerhas the ability to function in an agentless and thin agent mode causing minimalburden on network resources and decreasing the challenges related todeploying additional agents in the environment. In addition, to this KeyManager can leverage the agent of the existing Tectia Manager if this is alreadyin use in the environment.

Through a centralized database approach utilizing either MySQL or Oracle, thekey manager can work via multiple backend and front end con guration pointswhich makes the management of fragmented network environments in acontrolled manner.

Direct integration into Active Directory and LDAP allows SSH User KeyManager to make use of existing account structures to simplify the keydeployment process and ensure the timely creation and remove of keys.

APIs permit key manager to easily integrate to possible already existingapproval processes within the enterprise and can function as the engine for keysetup and removal with no change to that existing process.

3. Conclusion

For enterprises today with widespread Tectia SSH and OpenSSH deployments utilizing publickey authentication the risk exposure remains signi cant. The lack of de ned processes tomanage key setups and removals provides an uncontrollable situation around the managementof an ever increasing number of trust relationships. Furthermore, with the regular cycle oforganizational changes large enterprises face, merger and acquisition activity, general employeeturnover, and migration towards virtualized environments, the lack of SSH key managementbecomes a critical security risk enterprises must address.

Alternatives such as Kerberos and the utilization of x.509 certi cates will also addresschallenges related to public key authentication, however each comes as well with their owncomplexities and limitations. Both approaches require signi cant, time consuming and often

expensive changes to the existing infrastructure and processes.

On the other hand, the approach of utilizing the already existing authentication infrastructuregives large enterprises a quick and cost effective manner to gain visibility over the outstandingtrust relationships in the environment. Once this visibility is achieved, a solution such asUniversal SSH Key Manager, provides a quick path to not only organize the relationships intological groupings, but makes the move towards a fully automated SSH user key managementprocess including deployment, unit changes and key removals much easier. Considering theinvestment and effort that in many cases has been put in to setup keys over the years, theUniversal SSH Key Manager can leverage and reutilize this investment and provide enterprisesa sensible solution to a major security concern.



10/10

www.ssh.com

the technical complexities and risks of public key authentication

Documents