Patent Application
20080052755
1. Field of the Invention
The present invention is generally related to the establishment of secure, fine-grained trust relationships between computer systems in multi-tier distributed computing environments and, in particular, to a system and methods of securely establishing the operative chain of trust down to the level of individual application program instances as loaded in real-time for execution on host computer systems.
2. Description of the Related Art
Distributed computing environments depend on mutually recognized trust relations among networked computer systems to establish consistent control over the access and utilization of shared resources. Conventional computer operating systems establish trust relations based simply on a shared confidence in the identity of users. Various known network security systems effectively enable a password authenticated user identity to be established within a defined network space, such as the domain controller architecture initially implemented in the Microsoft® WindowsNT® operating system and the various yellow-pages services implemented in variants of the Unix® operating system. Access control lists (ACLs) and similar user/group attributes established locally against particular computer resources then control whether any particular user is able to access and use a network resource.
Distributed computing environments have greatly increased in complexity as required to meet ever widening operational demands that arise from various topographical, commercial, and regulatory requirements. Since networked computer systems can be highly decentralized, the network security system must, as a practical matter, permit aggregated control to be delegated to and performed by a centralized security administrator. Commercial requirements for functionality, performance, and redundancy have driven adoption of multi-tiered server computing environments, employing distributed application and database servers, which require a chain of trust to be established across each tiered level. Recent regulatory requirements have increased the need to assure security over privacy related data and, further, provide an audit of access and delivery of the data. Consequently, a need to significantly improve the security throughout distributed computing environments and ensure the integrity of trust relations formed between computer systems exists.
Various efforts have been made to improve distributed security systems as an essential step toward establishing and maintaining distributed trust relations. These efforts include, among others, controlling access to specific resources by applications and other executables and securing network communications between executing applications. By controlling and, as appropriate, restricting access to certain computer resources, both untrusted and trusted but misused applications are prevented from abusing the pre-established trust relationship between the user and the computer system and, further, between computer systems within a distributed computing environment.
Restricted application access control systems typically build on existing password authenticated user identity systems in an attempt to securely manage the execution of specific application programs. For example, Fischer (U.S. Pat. No. 5,412,717) and Chan et al. (U.S. Pat. 6,505,300) each describe restricted execution environments implemented integral to the local operating system. The Fischer system conditions the execution of an application or other executable content within the restricted environment on local verification of a secure application signature. Known, unmodified applications are then permitted to execute subject to assigned constraints on the resources that can be accessed by the application. A constraint profile, which is locally associated with an application based on the identity of the application or application class, is used by the restricted execution environment to filter each attempt by an executing application to access a resource. Only accesses explicitly permitted are allowed to proceed. The Chan et al. system adds a fairly complex access control list capability to the constraint profile, thereby increasing the fine-grained specification of whether different resources, including other executing programs, may be accessed by an executing application.
Even where applications, as executed, are entirely well-behaved, maintaining a trust relationship across a distributed computing environment requires all communications between applications to be maintained secure against electronic attack, including interception, redirection, and eavesdropping. Secure communications are typically achieved by encrypting transmitted data, typically using a form of public key encryption. Secure communications channels are established in a variety of ways. Secure communications services can be added directly to the network operating system environment to support virtual private networks (VPNs). Typically, VPN communications systems provide a secure communications channel established between disparately located computer systems.
While preventing external attack, conventional VPNs are shared services that permit applications executing on either end-point computer system to use the communications channel, thereby remaining open to attack from other users and applications executing on the end-point systems. To reduce exposure to internal attacks, various approaches have been advanced to establish and control multiple, discretely encrypted VPN channels between the same end-point systems. For example, multiple virtual routers, each representing a separate VPN channel, can be established at each end-point. Ylonen et al. (U.S. Pat. No. 6,438,612) describes a multiple, virtual router system that supports independent encryption of each virtual router channel. Use of any particular router channel is determined by presentation of a uniquely corresponding virtual network identifier representing, effectively, an extended IP address. Multiple applications and other executable content assigned the same virtual network identifier, presumptively on the basis of equal trustworthiness, will use the same virtual router channel. Unfortunately, while increasing the number of VPNs available for use, internal attacks need only spoof a targeted virtual network identifier in order to gain access to communications between otherwise secured applications.
An alternate approach is to establish secure execution environments that internally provide for secure network communications. Conventionally, secure shell (SSH) containers are selectively executed on end-point computer systems as alternatives to the native shell execution environments provided by the host operating systems. Each secure shell, in turn, supports an execution context that enables execution of one or more contained or hosted applications. Network communications between independently hosted applications are filtered through and fully encrypted by the mutual operation of the secure shells. Thus, while the secure shells support a relatively more controlled environment for executing applications that could securely share a single communications channel, there are substantial complexity and security management issues inherent in reliably configuring multiple secure shell environments on multiple, disparately located computer systems. In addition, any internal attack that permits a compromised application to be executed as a secure shell hosted application is then able to gain access to the otherwise secure communications of the other commonly hosted applications.
Another conventional approach to ensuring secure communications between individual applications is to directly implement a security protocol, such as the secure sockets layer (SSL) protocol, as an integral part of the application itself. Conventionally, communicating applications must be specifically written to interact with and utilize the functions of the secure sockets layer implemented at each end of an otherwise shared communications channel. The available security functions, such as the ability to require certificate authentication of the participating applications, is, however, limited to the SSL API revision level commonly supported by the communicating applications.
While the SSL and, to varying extents, other application-level security protocols are accepted and used, there are inherent drawbacks to their use. Each application must be not only initially written to use a specific security protocol, but frequently revised to maintain compatibility with and support the functions available in later revisions of the protocol API. Furthermore, the available security operations are limited to the established set of procedures included in the security protocol specification. Protocol extensions to establish and enforce additional qualifications on the use of a secured channel, as may be appropriate in specific business processes, are generally not possible. Such extensions would have to be implemented as part of proprietary application programs and would therefore interoperate only between those applications.
Consequently, there is a distinct need for a secure mechanism capable of establishing trust relationships on and between computer systems including particularly to found the trust relationship at the point of loading applications for execution at any tier within a multi-tier distributed computing environment.
Thus, a general purpose of the present invention is to provide a system and methods of enabling a chain of trust to be established to individual application program instances as loaded as loaded in real-time for execution on host computer systems.
This is achieved in the present invention by providing a security server to qualify the execution of programs on networked host computer systems. The security server uses a database that stores pre-qualified program signatures and defined policy rules associating execution permission qualifiers with execution control values. The server executes a control program in response to execution requests received via a communications network interface from identifiable hosts, wherein a predetermined execution request received from a predetermined host computer system includes an identification of a program load request, request context related data, and a secure program signature. The control program determines an execution control value based on an evaluation of the execution request relative to the pre-qualified program signatures and defined policy rules. The execution control value is then returned to the predetermined host computer system to securely qualify the execution of the program identified from the program load request.
Thus, an advantage of the present invention is that a chain of trust can be established for individual processes by securely qualifying, in real-time, each individual program instance as loaded for execution. Based on administratively established policy rules and administratively pre-qualified secure program signatures evaluated in connection with the loading of an application image, the execution of the application can be securely qualified and explicitly denied, permitted, or permitted subject to policy rule specified execution time qualifications.
Another advantage of the present invention is that each program instance can be evaluated in the real-time process of being loaded by an external security server. A local policy enforcement module implemented as a component of the operating system permits intercept of all operating system calls that could result in the execution of a program and submits the load request for qualification by a network connected and therefore independently secured security server.
A further advantage of the present invention is that the security server qualifies the execution of programs for a well-defined community of host computer systems, thereby enabling trust relations to be established for individual application instances relative to their host computer system and, further, as a foundation for establishing trust relations between application instances executing in different host computers.
Still another advantage of the present invention is that the full capability provided by the evaluation of policy set rules is available to qualify and further constrain execution of program instances. The context associated with any request to load and execution a program is made available for selection of controlling policy set rules. Additionally, a secure signature of the program image requested for execution is also provided to control rule selection. Provision of the secure signature allows a path independent and therefore more secure and universal identification of the specific program requested for execution. Rule matching can therefore be extremely fine-grained, which provides substantial administrative flexibility.
Yet another advantage of the present invention is that the product of policy set rule evaluation can provide multiple possible determinations. Execution of a particular program instance can be specified as a result of rule evaluation to deny, permit, or permit subject to specified constraints. Applicable constraints can be specified to the same fine-grained level applicable to the matching of any of the policy set rules. Applicable constraints can define administrative limitations, such as logging levels and auditing alarms, and procedural limitations, such as execution permitted for only limited periods, at only limited times, or subject to controls on the data or other system resources otherwise available.
FIGS. 9A-B are block diagrams illustrating multiple modes of operation including local and remote encryption, compression, and tunnel routing in accordance with a preferred embodiment of the present invention;
The present invention enables fine-grained trust relationships to be securely established for individual application instances, which is applicable both to discretely qualify the execution of individual application instances and, further, qualify and secure communications between individual application instances as executed typically on network connected host computer systems. In the following detailed description of the invention like reference numerals are used to designate like parts depicted in one or more of the figures.
A typical network configuration 10 employing the present invention, as generally shown in
Communications channels, such as the channel between host computer system 12 and application server 14, are established under the secure control of a security appliance 22 operating through locally installed policy enforcement modules (PEMs) 24, 26. The security appliances 20, 22 may be physically discrete units configured for specific roles or, preferably, configured to support multiple roles as needed by the same physical unit. Even where a security appliance 20, 22 can support multiple roles, additional security appliances 28 can be employed to permit flexibility in the siting of physical devices, such as where a host computer system 30, including locally installed PEM 34, is distant from a security appliance 22 so as to be preferentially associated with a separate security appliance 28.
As illustrated in
On intercept of any interprocess communications request, whether a local domain interprocess communications channel (IPC) or network socket request, the requested access operation, along with authentication and authorization information derived from the application instance process context associated with the request, is reported to and processed through a rule-based policy set maintained by the security appliance 42. Based on the request and related information, an applicable set of policy rules are identified for evaluation against the provided information. Access operations if and as permitted under an applicable policy set are then enabled through the PEM to complete. Enabling rules may qualify the access operation, such as to specify the establishment of an encrypted communications channel through which the access operation is permitted and whether encryption operations are to be performed locally by the PEM or remotely through the security appliance 22. Where, similar to as shown in
In the particular case of a request to load a file for execution as an application instance 56, a representative file load request is prepared and forwarded by the PEM 48, 50 to the security appliance 42 for evaluation. Preferably, a secure digital signature of the requested file is generated and provided as part of the context authentication and authorization information submitted to the security appliance 42. Although the requested file is typically specified in an operating system call by a filesystem or UNC path, use of the generated signature preferably provides a location independent identification of the file upon which the determination to permit execution is based. In the preferred embodiments of the present invention, the security appliance 42 maintains a pre-verified signature database for the executable files against which policy determinations can be made. Based on the request data provided, the security appliance 42 determines whether the file load request is permitted and informs the PEM 48, 50 to either permit or deny the loading and execution of the requested file.
In the case of requests to create or accept an IPC communications session, the IPC session request and related context dependent information is submitted to the security appliance 42 for evaluation. The response from the security appliance 42 again determines whether the PEM 48, 50 enables the requested communications channel. By considering separately the initial request to create a channel and, on the target host computer system, the permission to first to receive the request and then accept connection to the channel, the security appliance 42 can evaluate the appropriateness of enabling the communications session with respect to both the requesting source and target processes down to the level of the individual source and target application instances and context associated authorizations. Additionally, by intercepting both the creation and acceptance of the communications channel session, the security appliance 42 can coordinate the operation of the source and destination PEMs, typically PEMs 48, 50 in establishing a unique encrypted communications session channel. Preferably, the security appliance 42 stores encryption keys defined through the policy set rules as applicable to the source and target application instances and operates to securely generate a session key unique for the particular communications channel session established. In authorizing the creation of an encrypted communications session, the session key is securely transmitted to the PEMs 48, 50 and used to secure the communication channel for the duration of the session.
A preferred architecture of a security appliance 60 is shown in
A policy database 70 is provided locally on the security appliance 60 to store policy rule sets. A policy parser, implemented as a component of the control program 64, executes to evaluate access requests as received by the security processor 60 against matching policy rule sets. Operation of the control program 64 and management of the policy database 70 are described in Network Media Encryption Architecture and Methods for Secure Storage, by Pham et al. (application Ser. No. 10/016,897; filed Dec. 3, 2001), which is incorporated herein by reference. The policy parser preferably implements decision tree logic to determine whether to allow a access request by matching details of the request and associated context authentication and authorization information against corresponding selectors of the policy rule sets. The type of the request, whether classed as a program load, IPC operation, data file access, or other, determines in part the relevant nature of the policy rule set selectors. Preferably, the stored rules are specified by a system administrator to detail the permitted operations against the various filesystem and communications resources protected by the security processor 60 further qualified by applicable authentication and authorization values and the time ranges within which a rule is operative. The specified authorization values and time ranges are referred to as the rule access attributes.
In the preferred embodiments of the present invention, the authentication data provided in connection with a request processed through the individual PEMs 24, 26, 32 is implicitly derived from the identifier of the process that originates the request. Preferably, a secure identification of the user initiating a particular request is established through use of a pluggable authentication module (PAM) or similar operating system based application security module. In accordance with the present invention, each PEM 24, 26, 32 intercepts the operating system calls made to authenticate local users relative to a current context processes. In particular, the return values for those calls are recorded by the PEM 24, 26, 32. Preferably, on recognition of a successful authentication, the local PEM 24, 26, 32 caches an authentication data record including at least the authenticating process identifier. This authentication data may also record related data including the type of authentication performed and details of the authentication return values. Authentication attempts, including related process context data, can be reported to and recorded by the associated security appliances 60 for auditing and other administrative purposes.
Thus, for requests to be processed through to a security appliance 60, the process identifier associated with the request, as determined on intercept by the local PEM 24, 26, 32 is used to retrieve a corresponding authentication data record. The process identifier is used either directly or by tracing through the chain of parent process identifiers maintained for the process context by the operating system to match an authentication data record process identifier. Where a context relevant authentication has not succeeded, a null authentication data record is returned. The request to the security appliance 60 is then prepared based on the contents of the authentication data record. The authentication data preferably includes the request process identifier and, as applicable, the linking parent process identifiers associated with the authentication data record. This allows the subsequent qualification of the request on the basis of the type of authentication performed and whether and to what extent inherited authentication is acceptable.
Depending on the class type of the request, the access attributes provided with a request can include the operation requested, the request source host computer IP address, the request target host computer IP address, a target resource identified by a path or other identifier, user identification, the source application instance session and process identifiers, and a secure signature and file size of the source application instance. The operative time of the request is provided at least implicitly by the communication protocol used to transfer the request to the security processor 60. Thus, for the class of file access requests, the access attributes provided include the file operation requested, such as open, read, write, append, delete, and move, and the applicable filesystem mount point, path, and file specification. For communications oriented requests, the access attributes provided will include the protocol type of the communication channel requested, the source and target port numbers, and the network operation request, such as open, read, write, and close. Thus, each request presented to the security processor 60 is evaluated by the control program 64 against the permissions matrix defined by the administratively defined policy rules to determine whether the request is permitted. Depending on the determined policy analysis result, a request response containing an enabled, qualified enable, or denied status value is returned to the source PEM 24, 26, 32.
A signature database 72 locally provided on the security appliance 60 is also accessible to the control program 64. Preferably, the signature database stores secure, SHA-1 based signatures for an administratively determined set of executable programs, including associated executable library files. A prototypical database, the National Software Reference Library (NSRL; www.nsrl.nist.gov) which contains signatures for many conventional executable programs, is available from the National Institute of Standards and Technology (NIST). Preferably, as illustrated in
The preferred procedure 90 of processing requests received by the control program 64 is shown in
The processing of communications requests 98, data access requests 100, and other requests 102 is similar with the principle difference being the request identification 98, 100, 102 and the authorization and access attributes are used directly 108 as a selector of the applicable policy rule sets. Additionally, where the result of the policy evaluation 112 is to enable the request, any ancillary processing specified by the enabling policy rule set, such as to generate encryption session tokens for establishing a secure communications channel, communicate with other security appliances 22, 28, retrieve an encryption key for cipher processing read/write data transfers, or retrieve compression parameters for use in the processing of read/write data, is performed 116. Any applicable product of the ancillary processing, such as encryption session tokens, is then returned 114 as part of the response message sent to the corresponding PEM 24, 26, 32.
In accordance with a preferred embodiment of the present invention, data access requests 100 may involve additional request qualifying data. For example, where the resource request identifies a read or write operation directed against the Windows registry, the qualifying data 108 preferably includes the target registry key, as derived by a PEM 24, 26, 32 relative to the operating system call that would initiate the request. The registry key name, as well as the request associated authentication and authorization data, is used to lookup 110 the applicable policy rules for evaluation 112. Again, the result of the policy evaluation 112 is used to determine the content of the request response message returned 114 by the control program 64.
The preferred system architecture 120 of a host computer or server system 12, 14, 30 is shown in
In accordance with the present invention, a PEM 146 is locally executed within the kernel space 138 as a component permitting interception of selected application program interface (API) and virtual filesystem function calls relative to the operating system 130. The specific mechanism for intercepting the calls is operating system type and version dependent, though generally performed by registering the PEM 146 with the kernel, where function intercepts are natively supported or otherwise by redirection of the call entry points on initialization of the PEM 146.
As shown in greater detail in
As a component of the operating system 130, the operating system kernel 160 is accessible by the operating system and network PEMs 152
The filesystem PEM 152
The PEM 152 communicates 166, as needed, with an assigned security appliance 60 through the network stock 150 using either a shared network interface 168 or a private network interface 170. By using the shared network interface 168, the assigned security appliance 60 may be remotely located on any connected intranet or public network accessible by the PEM 152 through the network stack 150. Thus, the PEM 152 may be implemented on a host computer system geographically situated in a completely different location, region, or country relative to the assigned security appliance 60, thereby allowing the security appliance 60 to be physically secured while remotely protecting, through strong encryption, any data accessible through the PEM 152 protected host computer system, including direct attached storage local to the host computer system. The PEM 152 can also be implemented in a notebook or other mobile electronic device that directly or wirelessly connects to a network accessible through the shared network interface 168.
Alternately, the private network interface 170, if provided, can be used to connect one or more host computer systems with an assigned security appliance 60 through a separate security network independent of any public or even intranet-shared network. Use of a private security network permits the connection to be made physically secure, enables use of alternate deployment configurations particularly where clear text data is exchanged with the security appliance 60, and ensures minimal latency in communications between a host computer system and security appliance 60 by removing the albeit small communications load between the PEM 152 and security appliance 60 from the shared network 168 data path nominally used by the application instance 154.
In connection with distinguishing a permitted network-based communications channel request, the assigned security appliance 60 performs the ancillary processing necessary to provide a session specific encryption key to the PEM 152. This session key is then utilized in operating system calls made from the PEM 152 via a cipher driver interface 172 to, as appropriate, encrypt and decrypt data in transit through the PEM 152. The cipher driver interface 172 interoperates with the native encryption and compression driver 134 and hardware coprocessor driver 136, if present, to manage the data processing preferably using the process 180 shown in
The alternate configuration 230, shown in
The preferred process 240 of securely qualifying an application instance for execution is shown in
Once a program file is loaded from the filesystem, whether loaded peremptorily or only subject to a successful access request, the program file is held from execution by the PEM 152. A program execution request 246 is then submitted to the assigned security appliance 60. This request preferably includes the secure hash calculated signature of the program image and the authorization data and access attributes determined by the PEM 152 for the program execution request call context. Based on the request, the corresponding policy rule set is evaluated to permit or deny execution of the program file. Where permitted, the permission can be either express or conditional. Particularly in cases where permission is conditional or denied, the ancillary policy implementation 116 preferably implements any administrative actions specified by the policy rule set, which may include actions such as providing an alert message to an administrative console, logging the request and associated data, issuing email and pager notices of the event to administratively set addresses and numbers, and generating execution qualifying control values to be returned to the PEM 152.
Thus, the response returned from the security appliance 60 includes at least a binary value defining whether execution of the program file is to be permitted or denied by the PEM 152. Where denied, the PEM 152 acting through the operating system kernel 160, terminates the execution target process and releases the program file image. Where permitted, the PEM 152 evaluates and implements any conditional execution control values returned from the security appliance 60. In a preferred embodiment of the present invention, these conditional control values determine operative restrictions, such as execution time period and priority, the issuance of local alert dialogs and logging levels, that are then imposed on the execution context of the application instance by the PEM 152. The loaded program file is then released to the operating system 160 to begin execution 248 in the target context as the application instance.
The preferred process 250 of initiating of a secure communication session between source and target program instances is shown in
On the specified target host computer system, the network call is resolved, based on the port and protocol specification, to a communications request directed to a specific program instance executing on the target host computer system. The communications request is functionally intercepted by the target executed PEM 152 and a corresponding session request is issued 260 to the security appliance 60 assigned to the target host computer system. This session request preferably includes the target process and process context related authentication data and access attributes and an identification of the source host computer system, port and protocol, as determined from the operating system kernel 160. Preferably, a secure signature of the binary image of the target program instance is also acquired and provided to the assigned security appliance 60. Depending on the applicable policy rules, qualification of the session request can be made dependent on any combination of the provided session request information. The qualification can be further dependent on the connection request information provided by the source host computer system. The session request information is sufficient for a security appliance 60 assigned jointly to the source and target host computer systems to determine the secure identity of the source program instance. Where separate security appliances 60 are assigned to the source and target host computer systems, the target assigned security appliance 60 obtains sufficient information from the session request to identify and, through secure interoperation, obtain the secure identity of the source program instance from the source assigned security appliance 60. Furthermore, the policy rules can consider other factors, such as time of day and number of current connections established with the target program instance, to finally determine whether the requested communication session is qualified and therefore to be enabled.
Where a communication session is qualified, a session encryption key is generated 262, either directly by a shared security appliance 60 or through negotiation between source and target assigned security appliances 60. For configurations where encryption processing is performed local to the source and target host computer systems, the session key is then passed to the respective PEMs 152. The communications request is then forwarded 264 from the target PEM 152 to the target application instance to complete the initialization of the secure communications session.
Once the communication session is established, protocol appropriate commands and data can be transferred through the communications tunnel represented by the communications session. These protocol commands and data are fully encrypted while in transit between the source and target PEMs 152 utilizing the unique session key generated for the specific combination of source and target applications instances. Thus, based on the generation of the unique session tokens as specified by the applicable policy set rules, a secure communications channel could be shared by multiple, similarly encoded sessions or, preferably, each channel can host a uniquely encrypted communication session securely bound specifically to the participating source and target application instances.
Where the command transaction is permitted, the security appliance 60 returns the session specific session key and, as may be appropriate for low-bandwidth channels, any applicable compression control data. Any data being transmitted is then optionally compressed 280 and the protocol command and data are encrypted 282 using the session key. In accordance with the present invention, each session key is held only transiently by the PEM 152 as necessary for encrypting the corresponding protocol command and data. The encrypted data is then transmitted 284.
On receipt 290, the PEM 152 determines the target process 292 for the received encrypted data, and prepares a qualification request 294 including an identification of the target process, process context and related data. The session key and any applicable compression data are returned, permitting the data to be decrypted 296 and decompressed as needed 298. The decrypted protocol command and any applicable data are then provided to the target program instance 300.
Finally, as generally shown in
Thus, a system and methods for providing for establishing a secure trust relationship between process contexts, down to the level of individual program instances, has been described. While the present invention has been described generally with reference to binary-based program instances, the present invention is equally applicable to controlling the execution of byte-coded and other encoding-based program instances.
In view of the above description of the preferred embodiments of the present invention, many modifications and variations of the disclosed embodiments will be readily appreciated by those of skill in the art. It is therefore to be understood that, within the scope of the appended claims, the invention may be practiced otherwise than as specifically described above.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 10780101 | Feb 2004 | US |
| Child | 11711996 | Feb 2007 | US |
