Access Control Excellence Centrally Managed SSH Many data centers are replacing unencrypted and unsecure communication protocols such as telnet and ftp with Secure Shell (SSH). SSH is a secure network protocol that is typically used in conjunction with public keys to protect the point-topoint communication between hosts. This allows for stronger authentication and secure tunneling of data between hosts even when they are operating in an otherwise unsecure network. Implementing SSH usually improves security, but it can also introduce problems.
The Challenge with SSH Key Management Many data centers are replacing unencrypted and unsecure communication protocols such as telnet and ftp with Secure Shell (SSH). SSH is a secure network protocol that is typically used in conjunction with public keys to protect the point-to-point communication between hosts. This allows for stronger authentication and secure tunneling of data between hosts even when they are operating in an otherwise unsecure network. Implementing SSH usually improves security, but it can also introduce problems. The first challenges come about primarily because of the large number of user and host keys that need to be managed. Let s first look at some of the aspects of both host and user key management. Host keys are used to verify the identity of the host in question and user keys are used to authenticate users. These are used in conjunction with SSH to strengthen the security for how systems are accessed. On the user key side, SSH can also streamline the way authentication is performed as the key is used to replace passwords when it comes to validating who the user is. Users manage their own keys and are in control of their own keys. Now that all sounds good, but there is a problem: the keys can be easily copied. If a key for authenticating a specific user is copied, you lose track of who is actually using the key to authenticate and open to door to fraudulent activity. When you are managing large numbers of keys, it is difficult to track if keys are copied. To eliminate this risk and effectively enforce the use of a new key, you need the ability to centrally revoke and/or change keys. Another problem with SSH is key distribution. Host keys, for example, need to be generated. Generating host keys can, in some cases, be done in a central way. But even where host keys can be centrally generated, there is still the problem of how to efficiently distribute the keys within the environment. On the other side of the coin we have the user keys. Many organizations today have no way of revoking keys from a central location. The lack of automated, centralized key revoking creates both operational and security risk headaches, depending on how the user authentication and authorization is handled. So as we see, the lack of SSH key management is not only an operational cost issue (added effort to inventory/distribute/recycle keys), it is also a major security and compliance risk. Realizing the lack of over site, SOX and PCI-DSS auditors are beginning to take a closer look at how organizations are managing their SSH key infrastructure. The increased scrutiny will add additional burden on the IT teams needing to respond to new compliance and audit requirements. 2
Centrally Managed SSH Some organizations approve access to key pairs through permissions in Active Directory, but that does not stop a rogue employee who had access to key pairs from abusing unrevoked access to key systems to cause damage. Other organizations are starting to utilize SSH key management systems to inventory and recycle keys, but managing these systems still takes time and effort. Automated SSH Key Management FoxT takes a different approach to remove the labor and risks inherent in SSH key management. With FoxT, you automatically acquire the SSH-based security policy dynamically from the FoxT security server as part of the authentication and authorization process, and avoid many issues related to the usage of SSH keys all together Featuring fine grained policy management, it is possible to grant SSH access based on subprotocol level allowing individual control of Interactive shell, X11 tunneling, Command execution, File transfers and Port forwarding. Automatic granularity to the sub-protocol level and automated enforcement over which methods are used as part of the authorization allows for more streamlined control in who has access to what (and how) within the environment. Central management of host-based SSH keys and being able to distribute these keys will help streamline access within the environment as well as allow for seamless single sign on to host and between hosts. Authentication and access from desktops to servers and between servers can be completely seamless and no password authentication is needed. This reduces password sharing and allows for single-sign-on by the user. In addition, the user access to a host or a group of hosts can be revoked centrally. This is regardless of authentication method used and how the user is trying the access the host(s). FoxT also blends Active Directory with SSH to provide Kerberos-enabled SSH. This functionality allows for transparent Kerberos ticket retrieval directly from AD (or other Kerberos infrastructures) and the use of this ticket for authentication through the environment. Organizations enjoy additional control and flexibility in authenticating SSH users as well as the ability to automatically control access to file systems using the NFSv4 architecture. 3
The ability to automatically enforce SSH down to the sub-service level provides greater security and control over access policies For a scenario where a key is copied or becomes rouge, FoxT has mechanisms in place to prevent the key from being used on un-authorized systems. One aspect of the FoxT policy configuration includes controlling from where access to a specific system is allowed. If a key were to be copied and put on a rouge system, that system in itself would not be allowed as a source for accessing the targeted host, and therefore, access would not be allowed. Logging and reporting are also key aspects of access control processes. SSH activities are automatically logged in the FoxT infrastructure and can be reviewed in the FoxT Reporting Manager. Additional compliance reporting packs featuring tailored reports for SOX, PCI, HIPAA and NERC/CIPS can further reduce time you spend on audits and providing proof of your control over SSH. In summary, key capabilities of controlling SSH access with FoxT ServerControl includes: Sub-protocol granularity: Automatically enforce SSH access permissions granularly down to the sub-protocol level. Centralized SSH key management: Manage SSH keys and permissions policies for all users and hosts from a central console. Automatic key distribution: No specific key distribution or recycling is required as users automatically gain access to keys for hosts they are allowed to access as approved by the configured security policy. Single Sign On: Allows for seamless access to hosts based on SSH host keys. Kerberos-enabled SSH: Automatically control access to file systems using NFSv4 architecture. 4
Centrally Managed SSH Automatic SSH key enforcement: Acquire SSH security policy dynamically from the FoxT Server; each user automatically acquires the key of a target system once authorized by FoxT access policy. Compatibility: Supports External Digital Certificates and is fully compatible with other SSHv2 products. Consolidated audit and compliance reporting: SSH policies and user activities are all automatically logged and consolidated into audit and compliance-friendly reports 5
Copyright 2013 FoxT. All rights reserved. The document is provided for informational purposes only and the contents herein are subject to change without notice. This document is not warranted to be error-free, nor subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document. The document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior permission. FoxT logo is a trademark of FoxT, Inc. Other product and company names herein may be registered trademarks and trademarks of their respective owners. www.foxt.com 883 North Shoreline Blvd. Building D, Suite 210 Mountain View, CA 94043 USA 650.687.6300