Large enterprises have many thousands of server computers and tens of thousands or more of individual computing devices. Such organizations also typically use hundreds or thousands of different computer software applications in the course of their business, and have many, often hundreds of system administrators installing, maintaining, operating, upgrading, and otherwise administering these computers and applications.
Many applications provide different access or privilege levels for users. For example, a financial application might have privileged accounts that can be used to configure the system (e.g., select currencies used, create or delete accounts) and normal accounts that can only be used for day-to-day operations or data entry. For computer systems, there are typically normal user applications that are only used for running various application software, and administrator accounts (such as the root account in Unix/Linux or Administrator account and Domain Administrator account in Windows) that can be used to install, modify, or delete software on the system or access hardware (e.g., disk drives) directly, bypassing normal security and protection mechanisms on the computer (in practice, such accounts frequently permit kernel-level or operating system level access by allowing the installation of new device drivers or upgrading the operating system kernel). Given the large powers of certain administrator accounts, it is also possible to hide one's actions or insert hidden subvertive code into the system through such accounts.
Given the high number of administrators and the ability of some accounts to subvert even the operating system, it is important for organizations to monitor and audit access to and use of privileged accounts. This is important even for many medium-level privileged accounts where such auditing might still be required by regulations or good corporate governance policies. Furthermore, some applications might be so critical that all access to them should be audited, while others might ideally require real-time auditing and control from more than one person while performing administrative actions.
Several commercial products exist for controlling and auditing actions by administrators.
The PowerBroker product from BeyondTrust, Inc. permits fine-grained control and auditing of certain administrative actions.
The Xsuite products from Xceedium permit monitoring of SSH (Secure Shell) and RDP (Remote Desktop Protocol) sessions by requiring all administrative connections to be made through a centralized server, which decides which administrative interfaces a user can connect to and audits the actions performed by the administrator. It has access to the plaintext of even encrypted connections by making the connection from the centralized server and providing an HTTP-based web connection to the administrator. A shortcoming of the solution is that it forces administrators to use the user interface and tools provided by the solution; it is thus intrusive and changes the way administrators need to work.
The Privileged Session Management Suite from Cyber-Ark has similar capabilities and functionality as the Xceedium product, and suffers from similar shortcomings.
The Shell Control Box from Balabit also permits monitoring and auditing of SSH, RDP, VNC (Virtual Network Computing), and certain other types of sessions. While it can be operated in Bastion Mode, which is somewhat similar to the aforementioned products, it can also act as an intermediate device in the network between the administrative user and the computer running the application to which the administrative connection is. It performs a man-in-the-middle attack on the cryptography, which enables it to decrypt, inspect, and record even the contents of encrypted communications protocols. However, performing such attack smoothly requires that the intermediate device has a copy of the private key of the host being connected to, called destination host (for SSH), or a private key and certificate for the destination host (for, e.g., RDP). If the host key of the destination host is changed (it is prudent security practice to change any keys regularly), the key must be changed also on the intermediate device. When there are many hosts and many applications, this becomes very cumbersome. Furthermore, such keys may also be stored in, e.g., SSH clients, resulting in very confusing error/warning messages to end users when the keys are changed.
The Shell Control Box is frequently installed next to a firewall and stores all audit data on the Shell Control Box itself. Sometimes it is installed next to the server. When there are multiple firewalls or multiple servers to protect (possibly at different sites in widely separated geographic locations), logs from multiple users will remain at each Shell Control Box and since sensitive user data (including passwords) is stored at each device, compromise of even a single device may result in compromise of sensitive passwords. Centralized searches from multiple Shell Control Box installations are not possible.
The SSH protocol is described in the Internet Engineering Task Force (IETF) standards RFC 4250 The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4251 The Secure Shell (SSH) Protocol Architecture, RFC 4252 The Secure Shell (SSH) Authentication Protocol, RFC 4253 The Secure Shell (SSH) Transport Layer Protocol, and RFC 4254 The Secure Shell (SSH) Connection Protocol. The original protocol was invented and developed by one of the present inventors in 1995-1999, and then standardized by the IETF.
The Secure Shell (SSH) protocol and related client and server software applications are now included in nearly all Unix and Linux versions, such as IBM AIX, HP-UX, Solaris, Red Hat, SUSE, Ubuntu, etc. Popular implementations of the SSH protocol include the open source OpenSSH, which is based on the present inventor's free SSH version 1.12 from 1995, and the commercial Tectia SSH client and server from SSH Communications Security (Tectia Corporation).
The Secure Sockets Layer (SSL) protocol is described in RFC 6101. Its newer version, Transport Layer Security (TLS) protocol is described in RFC 5246.
The Remote Desktop Protocol is based on, and an extension of, the ITU T.120 family of protocols. It is described in detail in Microsoft documentation, available with the Microsoft Developer Network product, under the entry [MS-RDPBCGR]: Remote Desktop Protocol: Basic Connectivity and Graphics Remoting Specification, Microsoft Corporation, Dec. 14, 2011.
An objective of the present invention is to provide an improved system for controlling and auditing SFTP file transfers and file transfers using other encrypted protocols.