WHITE PAPER TAMING THE BEAST CONTROLLING SSH FOR SECURITY AND COMPLIANCE. Fox Technologies, Inc

Transcription

1 WHITE PAPER TAMING THE BEAST CONTROLLING SSH FOR SECURITY AND COMPLIANCE Fox Technologies, Inc

2 Taming the Beast: Controlling SSH for Security and Compliance SSH is nearly ubiquitous in today s enterprises, and is the predominant tool for managing unix and linux servers, and the applications and data that they host. Poor practices around the deployment and management of the SSH infrastructure could easily leave your enterprise vulnerable to a breach. Are you in control? 15% Compared to last year s study released in June 2013, the average total cost of a data breach has jumped 15 percent, from $3.1 million to about $3.5 million, with the average cost of a single lost or stolen record totaling $145 up from $136 last year. (1) SSH, Secure Shell protocol, is now nineteen years old and broadly deployed across almost every enterprise server and PC in your organization. It is also widely implemented in home networking broadband modems and routers, digital TV set top boxes, DVD players, tablet computers, smart phones, and (although not an advertised feature) even in-car entertainment and engine management systems, including inside the electric Tesla car. SSH provides for a secure connection and transport protocol for user and machine-to-machine (M2M) sessions. This means the SSH suite is a must-use toolkit for your system admin and support staff. Often this involves enabling access to higher privileges to perform administrative tasks, or to access specific servers that house sensitive information. The compromise of an account with any privileged access can shut down applications, expose data in that one environment, and become a launching off point to expose other critical systems on your network to attack. The loss of sensitive information that an enterprise is bound by regulation to protect is costly to repair, and will cause enormous damage to both your team s and company s reputation. Like any service that allows a remote host or device to connect to a computer, SSH can be attacked or abused. Compromise of a system via SSH often happens by attacking the authentication required to connect. This can be achieved using a stolen password or pass phrase, and is frequently combined in association with stolen SSHkeys. SSH does allow for some basic controls over how it is used. The SSH service runs on each computer, however it is typically controlled by local configuration text files. Each system that is running SSH has its own edition of configuration files that define: how the service is offered how connections can be established how a connection can be authenticated and to a degree, who has access The configuration of the various SSH services are the rules that are enforced when someone, or something, tries to connect. Unfortunately, systems and application administrators, who are required to have access to your critical infrastructure that hosts your most sensitive data, can easily abuse their privilege and change the rules. If the rules are on paper, and not enforced by central management, your staff can ignore the rules. Unmanaged Fox Technologies, Inc. sales@foxt.com

3 without enterprise-wide controls, SSH is the recipe for a nightmare scenario. A recent study has declared that administrators and end users are leaving back-doors open for SSH protocols for accounts that provide Linux root or Windows Administrator access to almost every server, virtual machine, and cloud service within the enterprise. The back-door is typically an unapproved and unmanaged account outside of enterprise controls, and in violation of enterprise policy. Additionally, for their own convenience the admin staff is often populating SSH user-keys to allow a singlesign-on feel to it. Their simple desire to NOT type a password or pass phrase can leave your enterprise vulnerable to attack. WHAT ARE SSH KEYS SSH keys are used all the time, in every connection. Confusingly there are two types of keys: user-keys and host-keys. Host-keys are used during the connection setup to provide a secure channel for authentication and can be likened to the SSL certificate on an e-commerce web server that is meant to protect the connection. However, unlike website certificates, Host-keys are typically unmanaged. They are created when the server is installed and hardly ever renewed. Currently it is the responsibility of the end-user to verify that the connection to the host is trusted before authenticating and exposing their login credentials (password) to the server. How would they know? The answer to the question do you trust this host? is usually a default and automatic response of yes. An unwary user may accept an untrustworthy connection and facilitate a man-in-the-middle attack that steals their password. However, due to the static nature of host keys living inside each server operating system, and without central management and automatic key rotation processes, most SSH enterprise configurations tend to avoid using them for user access. User-keys are a different story. User-keys provide a different type of functionality. These keys can replace the username/password paradigm, and are used to authenticate an account to a system. Most often the legitimate use of these keys in an enterprise is to allow for automated connections from one machine to another (M2M) to perform an automated or scheduled task. These services still require an account to log into, which are often called functionalaccounts or service-accounts, and are created to be used by an application, not by a person. The problem is that once SSH user-keys are allowed, they are hard to control. In the SSH configuration you can choose to allow keys, or not. If user-keys are allowed, then all you have to do is place a user-key on the target system and it can be used to gain access. Again, the use of SSH user-keys for authentication can have a legitimate purpose within an enterprise. Some organizations have scripts semi-automating key distribution to well-known servers. The problems arise when new infrastructure is established and not known to your scripting environment, or manual key movements are made by admin staff. 44% Forrester surveyed 151 U.S. enterprise IT decision makers responsible for IT security and found that of the 82% of organizations who depend on SSH, only 44% indicated that they are monitoring and logging how many SSH keys are deployed in their environment and what those authorizations are being used for. (2) CONTROLLING THE SIMPLE STUFF In a typical deployment, SSH relies on local authentication and access controls configured on each system. With only a few servers and a few accounts this may be manageable. As the number of hosts Fox Technologies, Inc. sales@foxt.com

4 and accounts grow, the administrative burden grows exponentially, to the point of becoming difficult or dangerous. Here are some broad guidelines: 1. Your company s user accounts need to be managed in one place. When access for an account needs to be disabled, it can be done centrally. Imagine having to disable an account and its SSH keys on ten, a hundred or thousands of servers if an administrator were to leave an organization. Missing even one server has the potential of allowing entry, and exposing the entire infrastructure to attack. 2. With most centralized access management systems you can also manage which server, or group(s) of servers an account is allowed to access. Not every user account should require access to every system. Limiting access is a fundamental security tool. 3. Create a management group for a role, add user accounts to the group going forward, and allow role-based-accesscontrol (RBAC). Creating access and authentication rules for defined teams of people are a lot more efficient than making adjustments individually. 4. Another benefit of centralizing authentication to many systems in an account is password management. Having to remember only one password is much better than having to remember many. It is a best practice to require passwords to be changed periodically, and this is much easier to implement and enforce when accounts are managed in one place. 5. The from-user and to-user SSH keys need to be known at both ends of a session to secure the channel. Choose a solution that can automatically make them available when the user attempts to connect. Pre-populating keys to servers on a might be needed basis is both inefficient, and prone to later non-removal as the user leaves your company or changes role. 6. Your administration and support staff have been using SSH for a long time. One quirk of behavior you should recognize is that they are used to self-creating their own SSH user-keys, even in an enterprise organization. Use a solution that allows these user generated keys to be transferred into a managed framework, and take control centrally. THE NEXT STEP: CENTRALIZING SSH SESSION ACCESS CONTROL Once you have decided which keys to authenticate with, you need to contend with the default behavior of SSH. This is what we like to call the all access key. The SSH suite of tools allows you to access servers and devices in multiple ways: log into a shell on a remote server/device executing a single command on a remote server/device secure file transfer back up, copy, and mirror files efficiently and securely forwarding or tunneling a network port full-fledged encrypted VPN forwarding X-Windows from a remote host browsing the web through an encrypted proxy connection securely mounting a directory on a remote server as a file system on a local computer automated remote monitoring and management of servers through one or more of the mechanisms discussed above If you have a valid host or user-key by default, you are then allowed to use any SSH door to gain entry to a server. If a key has been stolen or copied, a hacker can use any door to access the power of all of the above mechanisms. To ensure SSH is being used correctly, centralized SSH control also needs to include the following: 1. Separate access control locks on each of the SSH doors, enabling you to strictly control which parts of SSH functionality you want to make available as part of a user s normal role, and where in your server estate each door can be used. 2. Ensure the SSH solution you purchase ACTUALLY HAS locks available for every SSH door. Some products may only have simple locks for the first three mentioned on the list above. That still leaves seven other ways to compromise the security and data on your servers. Fox Technologies, Inc. sales@foxt.com

5 There are often valid reasons to allow a team leader the use of SSH to remotely transfer files between environments. For instance, the automatic transfer of clock-in and clock-out data to allow HR software, located elsewhere, to calculate weekly payroll. However, you may not want the team leader to be able to log into the HR server s operating system because they could manipulate the data file before it is loaded into the HR database. With standard SSH, and a valid key, that is VERY possible. FOXT BOKS SERVERCONTROL FoxT BoKS ServerControl is utilized by both multi-national enterprises that must comply with stringent compliance regimes, and small start-up companies that have commercial and customer confidential data. FoxT s automated credentials management and enforcement approach gets organizations out of the SSH key management business, enabling them to increase the granularity of access enforcement, and easily meet strict compliance regulations, all while taking full advantage of the benefits of SSH without the operational cost impact. 1. Centralizing user management in one place. If a staff member leaves, any accounts, passwords, keys, and roles can be switched off immediately. 2. Allowing you to create meaningful business and technical roles, which provide sensible connection points to attach SSH access policies, rather than with individual users. 3. Enabling you to define which keys are used where for SSH sessions, and how keys are automatically made available and used for user sessions, without assigning staff to handle SSH key distribution as an ongoing administration burden. 4. Enforcing which of ALL the SSH protocol doors can be used, and where. 5. Centrally logging all sessions to ensure you will pass your technical audits. 6. Stopping you from needing external scanning tools to discover historical SSH keys widely distributed across your infrastructure. If your organization has been in place for a while, expunging that stuff manually can be expensive. If the key is not registered with BoKS ServerControl, and associated with the correct user and door, it cannot be used - period. 7. Protecting you against using policies defined by mal-configured local SSH configuration files, or files that have been purposely tampered with by your staff or technical support partners. 8. Protecting you with locks on all the doors, and keys only being used in the right places at the right times, and providing you with centralized control of SSH. (1) 2014 Cost of Data Breach Study, Ponemon Insitiute, Sponsored by IBM (2) Survey: Centralized SSH security can help avoid high-profile breaches (3) Verizon 2014 Data Breach Investigations Report Not all software is created equal. FoxT BoKS ServerControl protects you from the shortcomings of standard SSH software by: Fox Technologies, Inc. sales@foxt.com

6 ABOUT FOXT Fox Technologies, Inc. helps companies protect corporate information assets with network security and access management software as well as striving to simplify compliance and streamline administration with an award-winning access management and privileged account control solution. Our access management software centrally enforces granular access entitlements in real time across diverse server environments. To learn more about Fox Technologies and BoKS ServerControl, please visit us at: CONTACT INFO North America 3300 Eagle Run Drive NE, Suite 202 Grand Rapids, MI (Toll Free) Sweden FoxT Sweden AB Kungsängsgatan 18A SE , Uppsala (Main) United Kingdom 400 Thames Valley Park Reading, Berkshire RG6 1PT (Main) Fox Technologies, Inc