Patent Description:
Using traditional authorization techniques, a single credential is often authorized to access two or more protected computer network resources based on either a persistent or a time-based assignment of a privilege group to the credential (where the privilege group grants access to the two or more protected resources). This single credential being authorized to access a plurality of resources is the underpinning of lateral traversal attacks, and escalation of privilege, within a computer network. For example, once this single credential has been compromised by a malicious party (e.g., due to social engineering, due to a software vulnerability, etc.), the malicious party can potentially discover one or more other protected resources in the privilege group and then use this credential to laterally traverse to any of the discovered protected resources to which the assigned privilege group grants access. Sometimes malicious parties wait years to discover another protected resource in the privilege group through observation. Once the malicious party has laterally traversed to a new system, that party may have the opportunity to compromise a new credential at the new system. When this new credential belongs to a privilege group that grants access to one or more additional systems, the malicious party can use this new credential to laterally traverse towards a further goal, such as a target credential or system of interest. Thus lateral traversal is use of a credential, compromised through access to a first protected resource, to access a second protected resource. <CIT> describes techniques for generating and using rule-enhanced access tokens in connection with authorization for access to resources. An access token is generated in response to determining that a user is authorized to access a protected resource. The access token contains rule information including one or more constraints, each constraint corresponding to a condition for granting or denying access to the protected resource. Upon receiving the access token, a client application can present the access token for accessing the protected resource. The client application can be configured to enforce one or more rules represented in the rule information. The client application can, for example, determine based on the one or more constraints that a condition for granting access is unmet and, in response, cancel a pending access request for the protected resource. <CIT> describes a cloud computing system which includes a physical resource pool that includes a number of information processing devices. Each information processing device includes a processor, a computer-readable medium, and a network interface. The system further includes a first cloud controller to manage a first cloud infrastructure, the first cloud infrastructure operating a first set of virtualized resources, the first set of virtualized resources having access to the physical resource pool through the first cloud controller. The system further includes a second cloud controller to manage a second cloud infrastructure, the second cloud infrastructure utilizing the first set of virtual resources to operate a second set of virtual resources, the second set of virtual resources being provided access to the physical resource pool through the second cloud controller and the first cloud controller. <CIT> describes a method to manage access to end user-protected resources hosted in a shared pool of configurable computing resources, such as a cloud computing environment, begins by registering a particular application or service into the environment. The application or service is one that is being permitted to access resources on behalf of end users via a delegated authorization protocol, such as OAuth. For at least one end user associated with the organization, a permission is set, preferably by an organization entity, such as an organization administrator. The permission determines whether the application or service is permitted to access one or more resources associated with the end user. Then, in response to a request by the third party application to access a resource, where the request is received via the delegated authorization protocol, the permission is then used to determine whether the third party application is permitted to access the resource. <CIT> describes improved techniques for managing enterprise applications on mobile devices are described herein. Each enterprise mobile application running on the mobile device has an associated policy through which it interacts with its environment. The policy selectively blocks or allows activities involving the enterprise application in accordance with rules established by the enterprise. Together, the enterprise applications running on the mobile device form a set of managed applications. Managed applications are typically allowed to exchange data with other managed applications, but are blocked from exchanging data with other applications, such as the user's own personal applications. Policies may be defined to manage data sharing, mobile resource management, application specific information, networking and data access solutions, device cloud and transfer, dual mode application software, enterprise app store access, and virtualized application and resources, among other things. <NPL> describes strategies and mitigations that are available with the release of features in Windows <NUM> / Windows Server <NUM> R2 to address Pass-the-Hash (PtH) attacks. Prior knowledge of PtH attacks and the previously published mitigations are expected. Additional background information is provided in Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft Techniques. The primary audience for this paper includes system administrators, security architects, and executives who understand IT security concepts and risk management. Its purpose is to enable organizations to create a comprehensive defense plan using the recommended strategies and latest updates to the Windows platform. The paper begins by providing strategies and considerations to help prevent attacks and overcome challenges related to identification, protection, detection, response, and post-compromise recovery scenarios. In order to gain a more resilient defense, it is important for organizations to protect, detect, respond, and recover in a continuous ongoing effort. The second half of the paper provides more information about the available technical mitigations that support these strategies, including a brief overview of the previous paper, key points about what has changed since its publication, and features introduced with the release of Windows <NUM> and Windows Server <NUM> R2 that help mitigate credential theft. In the "Sample scenarios" section, the reader will find example cases, including helpdesk and administrative support, to understand risks and what mitigations can be used.

At least some embodiments described herein confine lateral traversal within a computer network. In particular, in embodiments, a plurality of protected resources (e.g., computer systems, services, etc.) are grouped into one or more subsets of resources. Then, for at least one protected resource that is a target of an access request, embodiments configure an authority to enforce a policy that authorizes a request for access to the target protected resource only when the access request originates from an origin protected resource that is in a same subset as the target protected resource. In other words, the authority only authenticates an access request when the access request originates within a particular subset, and when the access request is destined to this particular subset. This means that if an access request originates from a resource that is in any subset other than the subset to which the target protected resource belongs, the authority denies the access request-even if the access request includes a credential that would otherwise be validly configured for access to the target protected resource (e.g., based on a group membership).

By grouping protected resources into subsets, and by enforcing policies that restrict access across subsets, the embodiments described herein limit the lateral traversal potential of a compromised credential. In particular, when a malicious party compromises a particular resource, including compromising a credential associated with that resource, the embodiments described herein restrict that malicious party from laterally traversing to (and compromising) any protected resources or associated credentials that are outside of the subset to which this particular resource belongs. As such, the embodiments described herein are capable of limiting lateral traversal to resources within the same subset as a compromised resource. Thereby, the embodiments described herein confine lateral traversal to resources within that subset.

Technical effects of limiting lateral traversal to resources within the same subset as a compromised resource, and confining lateral traversal to resources within that subset are given. This, in turn, improves system security, by limiting the scope of protected resources that a malicious party is capable of reaching and compromising within a computer network.

In some aspects, the techniques described herein relate to a method, implemented at a computer system that includes a processor, for confining lateral traversal within a computer network, the method including: receiving an authorization request that includes (a) an authentication token that identifies a credential and a first protected resource within the computer network, and (b) an identifier of a second protected resource within the computer network for which authorization is requested; determining, based on a capability of the credential, whether or not the credential is configured for access to the second protected resource; identifying a lateral traversal policy associated with the second protected resource, the lateral traversal policy constraining access to the second protected resource to only resources within the computer network that belong to a particular subset of resources to which the second protected resource belongs; determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs; and based at least on determining that the credential is configured for access to the second protected resource, performing one of: when the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs, issuing an authorization token that authorizes the credential to access the second protected resource via the first protected resource; or when the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs, denying the authorization request.

In some aspects, the techniques described herein relate to a method, wherein the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs, and the method includes the issuing the authorization token. In some aspects, the techniques described herein relate to a method, further including configuring a network to permit network communications from the first protected resource to the second protected resource.

In some aspects, the techniques described herein relate to a method, wherein the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs, and the method includes the denying the authorization request. In some aspects, the techniques described herein relate to a method, further including logging denial of the authorization request, including logging the credential, the first protected resource, and the second protected resource. In some aspects, the techniques described herein relate to a method, further including configuring a network to deny network communications from the first protected resource to the second protected resource. In some aspects, the techniques described herein relate to a method, further including, prior to denying the authorization request, determining that no exception applies to a lateral traversal denial between the first protected resource and the second protected resource.

In some aspects, the techniques described herein relate to a method, wherein the first protected resource and the second protected resource is each one of a computer system or a network service.

In some aspects, the techniques described herein relate to a method, wherein the authentication token is a ticket-granting ticket (TGT), and the authorization token is a client-to-server ticket issued by a ticket-granting service (TGS).

In some aspects, the techniques described herein relate to a method, wherein the lateral traversal policy defines the second protected resource to be part of the particular subset of resources to which the second protected resource belongs.

In some aspects, the techniques described herein relate to a method, wherein the credential is configured for access to the second protected resource just-in-time.

In some aspects, the techniques described herein relate to a method, wherein the capability of the credential is a group membership associated with the credential.

In some aspects, the techniques described herein relate to a method, wherein determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs includes comparing a first subset membership attribute of the first protected resource with a second subset membership attribute of the second protected resource.

In some aspects, the techniques described herein relate to a method, wherein the authentication token also identifies one or more attributes of the first protected resource, and wherein the one or more attributes of the first protected resource are utilized for at least one of: (a) the determining whether or not the credential is configured for access to the second protected resource, or (b) the determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs.

In some aspects, the techniques described herein relate to a computer system for confining lateral traversal within a computer network, including: a processor; and a hardware storage device that stores computer-executable instructions that are executable by the processor to cause the computer system to at least: receive an authorization request that includes (a) an authentication token that identifies a credential and a first protected resource within the computer network, and (b) an identifier of a second protected resource within the computer network for which authorization is requested; determine, based on a capability of the credential, whether or not the credential is configured for access to the second protected resource; identify a lateral traversal policy associated with the second protected resource, the lateral traversal policy constraining access to the second protected resource to only resources within the computer network that belong to a particular subset of resources to which the second protected resource belongs; determine whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs; and based at least on determining that the credential is configured for access to the second protected resource, perform one of: when the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs, issue an authorization token that authorizes the credential to access the second protected resource via the first protected resource; or when the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs, deny the authorization request.

In some aspects, the techniques described herein relate to a computer readable media that stores computer-executable instructions that are executable by a processor to cause a computer system to confine lateral traversal within a computer network, the computer-executable instructions including instructions that are executable by the processor to cause the computer system to at least: receive an authorization request that includes (a) an authentication token that identifies a credential and a first protected resource within the computer network, and (b) an identifier of a second protected resource within the computer network for which authorization is requested; determine, based on a capability of the credential, whether or not the credential is configured for access to the second protected resource; identify a lateral traversal policy associated with the second protected resource, the lateral traversal policy constraining access to the second protected resource to only resources within the computer network that belong to a particular subset of resources to which the second protected resource belongs; determine whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs; and based at least on determining that the credential is configured for access to the second protected resource, perform one of: when the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs, issue an authorization token that authorizes the credential to access the second protected resource via the first protected resource; or when the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs, deny the authorization request.

<FIG> illustrates an example computer architecture <NUM> that facilitates confining lateral traversal within a computer network. As shown in <FIG>, computer architecture <NUM> comprises an authority <NUM> connected via a network <NUM> (or a plurality of networks) to a plurality of protected resources (e.g., protected resource 103a to protected resource 103n arranged into a subset <NUM>, protected resource 105a to protected resource 105n arranged into a subset <NUM>, and/or protected resource <NUM> that is outside of any subset). In some embodiments, the authority <NUM> is a ticket-granting service (TGS) that operates according to the Kerberos protocol. However, as will be appreciated by one of ordinary skill in the art, the principles described herein can be applied a broad variety of authentication/authorization technologies beyond Kerberos. In embodiments, a protected resource can comprise any resource from which an authorization request can originate, and/or any resource that can be a target of an authorization request. For example, in embodiments, a protected resource comprises a computer system or a network service.

As shown in <FIG>, the authority <NUM> communicates with (or, in some embodiments, comprises) a directory <NUM> which stores at least credential records <NUM> and resource records <NUM>. In some embodiments, the directory <NUM> stores these records using an object data model, such as a data model defined by the X. <NUM> standards electronic directory services, a data model used by ACTIVE DIRECTORY from MICROSOFT CORPORATION, etc. In embodiments, the directory <NUM> is accessible using the Lightweight Directory Access Protocol (LDAP), Active Directory Lightweight Directory Services (AD LDS), etc. However, as will be appreciated by one of ordinary skill in the art, the principles described herein can be applied a broad variety of technologies beyond those named herein.

For purposes of describing the embodiments herein, the credential records <NUM> are shown as including at least a record <NUM> defining a credential <NUM> that is assigned a capability <NUM> (e.g., an assigned group membership). Additionally, the resource records <NUM> are shown as including at least a record <NUM> for protected resource 103a. This record <NUM> defines a subset membership for the protected resource 103a (i.e., subset <NUM>), a policy <NUM>, and an indication the protected resource 103a is accessible by credentials having capability <NUM> (e.g., credentials that have been assigned to a particular group). Notably, while-for clarity-<FIG> illustrates separate lines within record <NUM> for the subset definition and the policy <NUM>, in some embodiments the policy <NUM> includes the subset definition and/or presence of the subset definition implies presence of the policy <NUM> (e.g., as a Kerberos claim). Although not shown, in embodiments the resource records <NUM> include additional records for other protected resources (e.g., protected resource 103n, protected resource 105a, protected resource 105n) that, in embodiments, comprise analogous subset definitions and polices that authorize requests for access to those protected resource only when those requests originate from another resource that is part of the same subset as that resource.

In embodiments, the authority <NUM> is configured to utilize the directory <NUM> to process an authorization request received from an origin protected resource, and in which the authorization request is a request for authorization to access a target protected resource. In order to confine lateral traversal among protected resources, the authority <NUM> is configured to enforce a policy that authorizes a request for access to a target protected resource only when the access request originates from an origin protected resource that is in the same subset as the target protected resource. For example, the authority <NUM> is configured to enforce a policy <NUM> that is associated with protected resource 103a, which authorizes requests for access to the protected resource 103a only when those requests originate from another resource (e.g., protected resource 103n) that is also a part of subset <NUM>. This means the authority <NUM> is configured to deny any requests for access to protected resource 103a from resources that are outside of subset <NUM> (e.g., protected resource <NUM> that is outside of any assigned subset, protected resources 105a to 105n that are assigned to subset <NUM>, etc.)-even if that request identifies a credential (e.g., credential <NUM>) that would otherwise be validly configured for access to protected resource 103a (e.g., based on capability <NUM>).

Notably, by configuring the authority <NUM> to enforce policies that authorize requests for access to a given target protected resource only when that access request originates from an origin protected resource that is in the same subset as the target protected resource, the authority <NUM> limits the lateral traversal potential of a compromised credential. For example, if a malicious party compromises protected resource <NUM> and credential <NUM>, the authority <NUM> restricts that malicious party from using credential <NUM> to laterally traverse from protected resource <NUM> to protected resource 103a and thus prevents the malicious party from compromising protected resource 103a (or any additional credentials associated with protected resource 103a, but not with protected resource <NUM>). Similarly, if a malicious party compromises protected resource 105a and credential <NUM>, the authority <NUM> restricts that malicious party from using credential <NUM> to laterally traverse from protected resource 105a to protected resource 103a and thus prevents the malicious party from compromising protected resource 103a (or any additional credentials associated with protected resource 103a, but not with protected resource 105a).

<FIG> illustrates details of the authority <NUM>, including example components (e.g., a communications component <NUM>, a capability determination component <NUM>, a token issuance component <NUM>, a denial component <NUM>, and a lateral traversal prevention component <NUM>) that facilitate confining lateral traversal within a computer network, according to some embodiments. It will be appreciated that the depicted components-including their identity, sub-components, and arrangement-are presented merely as an aid in describing various embodiments of the authority <NUM>, as described herein, and that these components are non-limiting to how software and/or hardware might implement various embodiments described herein, or of the particular functionality thereof.

In embodiments, the communications component <NUM> communicates with protected resources over the network <NUM>, which can include receiving access requests from protected resources, and sending authorization tokens and/or denial messages to those protected resources in response. In some embodiments, the communications component <NUM> also communicates with the directory <NUM> to obtain records, such as credential records <NUM> and/or resource records <NUM>.

In embodiments, the capability determination component <NUM> identifies a capability associated with a credential that is included in an access request, and determines if that capability configures the credential for access to a target protected resource. For example, since credential <NUM> is assigned the capability <NUM> (e.g., an administrative group membership), that credential <NUM> is configured for access to protected resource 103a (e.g., since record <NUM> indicates that protected resource 103a is accessible by capability <NUM>).

In embodiments, when the authority <NUM> has determined that an origin protected resource is authorized to access a target protected resource (e.g., in response to receipt of an access request at the communications component <NUM>), the token issuance component <NUM> generates an authorization token for the origin protected resource. Conversely, when the authority <NUM> has determined that an origin protected resource is not authorized to access the target protected resource (e.g., in response to receipt of an access request at the communications component <NUM>), the denial component <NUM> generates a denial message.

In embodiments, the lateral traversal prevention component <NUM> operates to confine lateral traversal among protected resources, based on a subset membership of (or lack thereof) of an origin protected resource, based on a subset membership of a target protected resource, and based on a policy (associated with the target protected resource) that requests for access to the target protected resource should only be authorized when the access request originates from a resource that is within the a same subset as the target protected resource.

The lateral traversal prevention component <NUM> is shown as including a policy identification component <NUM>. In embodiments, the policy identification component <NUM> identifies and/or determines whether a lateral traversal policy exists for a given target protected resource. The lateral traversal prevention component <NUM> is also shown as including a subset membership component <NUM>. In embodiments, the subset membership component <NUM> determines to which subset each of the origin protected resource and the target protected resource belong. In some embodiments, presence of a subset membership within a resource record (e.g., record <NUM>) implies presence of a lateral traversal policy (e.g., as a Kerberos claim). Thus, in some embodiments, policy identification component <NUM> and the subset membership component <NUM> are a single common component.

The lateral traversal prevention component <NUM> is also shown as including a union determination component <NUM>. In embodiments, the union determination component <NUM> determines whether the authority <NUM> can grant access to the target protected resource, based on a union between a credential capability of a requesting credential and a lateral traversal policy restricting access to a target protected resource to only those origin protected resources that are in a common subset with the target protected resource. In embodiments, the union determination component <NUM> determines whether a credential capability (e.g., group membership) configures the credential for access to the target protected resource (e.g., is the credential configured for access to the target protected resource?), and whether an origin protected resource from which an access request was sent belongs to the same subset as a target protected resource (e.g., is the origin protected resource in the same subset as the target protected resource?). In embodiments, this union determines whether the authority <NUM> can grant access to the target protected resource, as shown in Table <NUM>:.

Operation of the components of the authority <NUM> are now further described in connection with <FIG>, which illustrates a flow chart of an example method <NUM> for confining lateral traversal within a computer network. In embodiments, instructions for implementing method <NUM> are encoded as computer-executable instructions stored on a hardware storage device that are executable by a processor to cause a computer system (e.g., authority <NUM>) to perform method <NUM>.

Operation of the components of the authority <NUM> are also further described in connection with <FIG>, which each illustrates an example communications timing diagram demonstrating handling, by the authority <NUM>, of an access request that is sent by an origin protected resource with an intent to access a target protected resource. In particular, <FIG> illustrates an example 300a of a communications timing diagram showing authorization of an access request sent by an origin protected resource that is in the same subset as a target protected resource; in <FIG>, protected resource 103n (subset <NUM>) is the origin protected resource, and protected resource 103a (subset <NUM>) is the target protected resource. Additionally, <FIG> illustrates an example 300b of a communications timing diagram showing denial of an access request sent by an origin protected resource that is in a different subset than a target protected resource; in <FIG>, protected resource 105a (subset <NUM>) is the origin protected resource, and protected resource 103a (subset <NUM>) is the target protected resource. Finally, <FIG> illustrates an example 300c of a communications timing diagram showing denial of an access request sent by an origin protected resource that is apart from any subset; in <FIG>, protected resource <NUM> (no assigned subset) is the origin protected resource, and protected resource 103a (subset <NUM>) is the target protected resource.

The following discussion now refers to a number of methods and method acts. Although the method acts may be discussed in certain orders, or may be illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed.

Referring to <FIG>, in embodiments, method <NUM> comprises an act <NUM> of receiving an authorization request identifying a credential, an origin protected resource, and a target protected resource. In some embodiments, act <NUM> comprises receiving an authorization request that includes (a) an authentication token that identifies a credential and a first protected resource within the computer network, and (b) an identifier of a second protected resource within the computer network for which authorization is requested. In embodiments, the first protected resource and the second protected resource is each one of a computer system or a network service.

Referring to <FIG> and <FIG>, in example 300a, at time (<NUM>) protected resource 103n sends an authorization request <NUM> to authority <NUM> over network <NUM>; the communications component <NUM> at authority <NUM>, in turn, receives that authorization request <NUM>. As shown, in at least one embodiment, the authorization request <NUM> comprises an authentication token <NUM> that, in turn, comprises an identity of credential <NUM> and an identity of protected resource 103n as the origin of the request. Additionally, the authorization request <NUM> also comprises an identity of the protected resource 103a as the intended target of the request.

Referring to <FIG> and <FIG>, in example 300b, at time (<NUM>) protected resource 105a sends an authorization request <NUM> to the authority <NUM> over the network <NUM>; the communications component <NUM> at authority <NUM>, in turn, receives that authorization request <NUM>. As shown, in at least one embodiment, the authorization request <NUM> comprises an authentication token <NUM> that, in turn, comprises an identity of credential <NUM> and an identity of protected resource 105a as the origin of the request. Additionally, the authorization request <NUM> also comprises an identity of the protected resource 103a as the intended target of the request.

Referring to <FIG> and <FIG>, in example 300c, at time (<NUM>) protected resource <NUM> sends an authorization request <NUM> to the authority <NUM> over the network <NUM>; the communications component <NUM> at authority <NUM>, in turn, receives that authorization request <NUM>. As shown, in at least one embodiment, the authorization request <NUM> comprises an authentication token <NUM> that, in turn, comprises an identity of credential <NUM> and an identity of protected resource <NUM> as the origin of the request. Additionally, the authorization request <NUM> also comprises an identity of the protected resource 103a as the intended target of the request.

As mentioned, in embodiments the authority <NUM> is a TGS that operates according to the Kerberos protocol. In these embodiments, the authentication token is a ticket-granting ticket (TGT) that was previously issued to the origin protected resource (e.g., protected resource 103n in example 300a, protected resource 105a in example 300b, or protected resource <NUM> in example 300c) by authority <NUM> (or some other entity) as part of authentication of credential <NUM> at that origin protected resource. However, it will be appreciated by one of ordinary skill in the at that many forms of authentication tokens and authentication requests could be utilized in order implement the principles described herein.

Notably, in some embodiments, an authentication token (e.g., authentication token <NUM> in example 300a, authentication token <NUM> in example 300b, or authentication token <NUM> in example 300c) comprises one or more attributes of the origin protected resource. In embodiments, these attributes are used by the authority <NUM> to make policy decisions. Thus, in some embodiments of act <NUM>, the authentication token also identifies one or more attributes of the first protected resource. In one embodiment, these attributes include an attribute specifying a subset membership of the origin protected resource, and this attribute used (e.g., in act <NUM>) to determine whether the origin protected resource is in the same subset as the target protected resource. Thus, in some embodiments, the one or more attributes of the first protected resource are utilized for the determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs. For example, in example 300a authentication token <NUM> may include an attribute specifying subset <NUM> (e.g., because the origin protected resource is protected resource 103n within subset <NUM>), in example 300b authentication token <NUM> may include an attribute specifying subset <NUM> (e.g., because the origin protected resource is protected resource 103n within subset <NUM>), and in example 300c the authentication token <NUM> may include an attribute indicating no subset (e.g., because the origin protected resource is protected resource <NUM> with no assigned subset). In some embodiments, an attribute specifying a subset membership of the origin protected resource is in the form of a Kerberos claim.

Referring to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> of identifying a credential capability. In some embodiments, act <NUM> comprises identifying a capability of the credential, the capability configuring the credential for access to one or more protected resources. For example, referring to <FIG> and <FIG>, the capability determination component <NUM> identifies a capability (e.g., capability <NUM>) associated with the credential (e.g., credential <NUM>) identified in the corresponding authorization request (e.g., authorization request <NUM> in example 300a, authorization request <NUM> in example 300b, or authorization request <NUM> in example 300c) received by the communications component <NUM> in act <NUM>. In embodiments, the capability determination component <NUM> identifies the capability by performing a lookup in the directory <NUM> (e.g., an X. <NUM> directory, ACTIVE DIRECTORY, etc.).

In some embodiments, the capability is an attribute, such as a privilege group membership (e.g., administrators), that is assigned to the credential. Thus, in some embodiments of method <NUM>, the capability of the credential is a group membership associated with the credential.

In some embodiments the capability is assigned to the credential persistently, while in other embodiments the capability is assigned to the credential on a time-based basis. For example, in these latter embodiments, the capability is assigned to the credential "just-in-time" during an attempt to access a target protected resource (e.g., protected resource 103a) using the credential, along with an expiration time period after which the capability is removed from the credential. Thus, in some embodiments of method <NUM>, the credential is configured for access to the second protected resource just-in-time.

Referring to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> of identifying a policy constraining access to the target protected resource to a subset of network resources. In some embodiments, act <NUM> comprises identifying a lateral traversal policy associated with the second protected resource, the lateral traversal policy constraining access to the second protected resource to only resources within the computer network that belong to a particular subset of resources to which the second protected resource belongs. For example, referring to <FIG> and <FIG>, the policy identification component <NUM> identifies a policy (e.g., policy <NUM>) associated with the target protected resource (e.g., protected resource 103a) that was identified in the corresponding authorization request (e.g., authorization request <NUM> in example 300a, authorization request <NUM> in example 300b, or authorization request <NUM> in example 300c) received by the communications component <NUM> in act <NUM>. In embodiments, the policy identification component <NUM> identifies the policy by performing a lookup in the directory <NUM> (e.g., an X. <NUM> directory, ACTIVE DIRECTORY, etc.).

As mentioned previously, in some embodiments the policy <NUM> includes a subset definition (e.g., that protected resource 103a is in subset <NUM>). Thus, in some embodiments of method <NUM> the lateral traversal policy defines the second protected resource to be part of the particular subset of resources to which the second protected resource belongs. In other embodiments presence of the subset definition implies presence of the policy <NUM>.

Notably, act <NUM> and act <NUM> are illustrated as being performed in parallel, indicating that there is no particular ordering required between act <NUM> and act <NUM>. Thus, in various embodiments, act <NUM> and act <NUM> are performed in parallel, or in serial (in either order).

Referring to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> of determining a union between the credential capability and the lateral traversal policy. As shown in <FIG>, in some embodiments, act <NUM> comprises an act <NUM> of determining (e.g., by the capability determination component <NUM>) whetherthe credential capability configures access to the target protected resource (e.g., is the credential configured for access to the target protected resource?), and an act <NUM> of determining (e.g., by the subset membership component <NUM>) whether the origin protected resource belongs to the subset (e.g., is the origin protected resource in the same subset as the target protected resource?). Based on these determinations, act <NUM> results in either a determination of a grant or a denial of access to the target protected resource by the union determination component <NUM>, as shown in Table <NUM>. Notably, act <NUM> and act <NUM> are illustrated as being performed in serial, with act <NUM> occurring prior to act <NUM>. However, in alternate embodiments act <NUM> and act <NUM> could be performed in reverse order, or even in parallel.

In some embodiments, act <NUM> comprises determining, based on a capability of the credential, whether or not the credential is configured for access to the second protected resource. Referring to <FIG> and <FIG>, in each of examples 300a, 300b, and 300c the capability determination component <NUM> determines that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>). In embodiments, this determination is based on the credential <NUM> having capability <NUM>, and based on the protected resource 103a being accessible by capability <NUM> (i.e., as indicated in record <NUM>).

As discussed in connection with act <NUM>, in some embodiments, the authentication token (e.g., authentication token <NUM> in example 300a, authentication token <NUM> in example 300b, or authentication token <NUM> in example 300c) comprises one or more attributes of the origin protected resource (e.g., protected resource 103n in example 300a, protected resource 105a in example 300b, or protected resource <NUM> in example 300c), including an attribute specifying a subset membership of the origin protected resource. In these embodiments, the capability determination component <NUM> uses this attribute as part of determining whether or not the credential is configured for access to the second protected resource. Thus, in some embodiments of method <NUM>, one or more attributes of the first protected resource are utilized for the determining whether or not the credential is configured for access to the second protected resource.

In some embodiments, act <NUM> comprises determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs. In embodiments, determining whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs in act <NUM> comprises comparing a first subset membership attribute of the first protected resource with a second subset membership attribute of the second protected resource.

Referring to <FIG> and <FIG>, in example 300a the subset membership component <NUM> determines that protected resource 103n belongs to the same subset of resources to which protected resource 103a belongs (i.e., both of protected resource 103n and protected resource 103a are in subset <NUM>), and that the origin protected resource is thus in the same subset as the target protected resource (i.e., "Yes" from act <NUM>).

Based on the outcomes of act <NUM> and act <NUM>, in example 300a act <NUM> results in a determination of a grant of access to protected resource 103a by the union determination component <NUM>, based on a determination that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>), and based on a determination that protected resource 103n belongs to the same subset of resources to which protected resource 103a belongs (i.e., "Yes" from act <NUM>).

Referring to <FIG> and <FIG>, in example 300b the subset membership component <NUM> determines that protected resource 105a does not belong to (i.e., is outside of) the subset of resources to which protected resource 103a belongs (i.e., protected resource 105a is in subset <NUM>, while protected resource 103a is in subset <NUM>), and that the origin protected resource is thus outside of the target protected resource's subset (i.e., "No" from act <NUM>).

Based on the outcomes of act <NUM> and act <NUM>, in example 300b act <NUM> results in a determination of a denial of access to protected resource 103a by the union determination component <NUM>, based on a determination that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>), and based on a determination that protected resource 105a is outside of a subset of resources to which protected resource 103a belongs (i.e., "No" from act <NUM>).

Referring to <FIG> and <FIG>, in example 300c the subset membership component <NUM> determines that protected resource <NUM> does not belong to (i.e., is outside of) the subset of resources to which protected resource 103a belongs (i.e., protected resource <NUM> is in no assigned subset), and that the origin protected resource is thus outside of the target protected resource's subset (i.e., "No" from act <NUM>).

Based on the outcomes of act <NUM> and act <NUM>, in example 300c act <NUM> results in a determination of a denial of access to protected resource 103a by the union determination component <NUM>, based on a determination that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>), and based on a determination that protected resource <NUM> is outside of a subset of resources to which protected resource 103a belongs (i.e., "No" from act <NUM>).

In some embodiments, the authority <NUM> permits definitions of exceptions that bypass enforcement of the lateral traversal policy (and thereby permit an access from a resource outside of a subset to which the target protected resource belongs, even when the lateral traversal policy would dictate otherwise). Thus, referring to <FIG>, method <NUM> may comprise an act <NUM> of determining if a traversal exception applies. In some embodiments, act <NUM> comprises, prior to denying the authorization request, determining that no exception applies to a lateral traversal denial between the first protected resource and the second protected resource. If act <NUM> is present, then when a traversal exception does apply method <NUM> proceeds to issuance of an authorization token at act <NUM> (i.e., "Yes" from act <NUM>); otherwise, method <NUM> proceeds to a denial of the authorization request at act <NUM> (i.e., "No" from act <NUM>).

For example, as an exception to the determination of act <NUM>, as shown in <FIG> some embodiments that include act <NUM> may grant access to the target protected resource when the credential capability is determined to configure access to the target protected resource (i.e., "Yes" from act <NUM>), even if the origin protected resource is determined to be outside of the target protected resource's subset (i.e., "No" from act <NUM>). In embodiments, this exception is based on a identifying a specifically-configured exception (e.g., stored at the authority <NUM> or at the directory <NUM>), such as an entry on allow list. In embodiments, this entry includes specification of a particular origin protected resource that, as an exception, can access a particular target protected resource even though it is outside of the target protected resource subset. In embodiments, this entry also includes specification of at least one credential that is permitted to use the exception. In some embodiments, a credential that is permitted to use the exception can do so regardless of an assigned capability, while in other embodiments a credential that is permitted to use the exception can do so only when it is assigned a particular capability (e.g., as specified in the entry).

Referring to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> of issuing an authorization token. In some embodiments, act <NUM> comprises, based at least on determining that the credential is configured for access to the second resource (i.e., "Yes" from act <NUM>), and when the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs (i.e., "Yes" from act <NUM>), issuing an authorization token that authorizes the credential to access the second protected resource via the first protected resource. Technical effects of issuance of an authorization token in act <NUM> include authorizing and enabling the origin protected resource to initiate a communications session with the target protected resource (e.g., by sending the authorization token to the target protected resource).

Referring to <FIG>, in example 300a the capability determination component <NUM> determines in act <NUM> that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>). Further, in example 300a the subset membership component <NUM> determines in act <NUM> that protected resource 103n belongs to the same subset of resources to which protected resource 103a belongs, and that the origin protected resource is thus in the same subset as the target protected resource (i.e., "Yes" from act <NUM>). Thus, act <NUM> results in a determination of a grant of access to protected resource 103a. As a result, and as shown in <FIG>, method <NUM> proceeds to act <NUM> of issuing an authorization token by the token issuance component <NUM>. For example, in <FIG>, at time (<NUM>) the authority <NUM> sends a reply <NUM> to the protected resource 103n over the network <NUM>. As shown, in embodiments, the reply <NUM> comprises an authorization token <NUM> which, in embodiments, comprises the authentication token <NUM> plus a signature by the authority <NUM> (as indicated by a key in the authorization token <NUM>). As shown at time (<NUM>), in embodiments the protected resource 103n uses this authorization token <NUM> to send an access request <NUM> to the protected resource 103a.

In some embodiments, the authorization token is a client-to-server ticket issued by a TGS, according to the Kerberos protocol. However, it will be appreciated by one of ordinary skill in the at that many forms of authorization tokens could be utilized in order implement the principles described herein.

Notably, in some embodiments, in addition to issuing an authorization token at act <NUM>, method <NUM> also comprises configuring a network to permit network communications from the first protected resource to the second protected resource. For example, embodiments may configure a network firewall service to allow network packets to pass from the first protected resource to the second protected resource, configure a network tunneling service to allow the establishment of a network tunnel (e.g., an IP Security tunnel) between the first protected resource to the second protected resource, and the like. In embodiments, this has a technical effect of permitting the communication of network packets from the first protected resource to the second protected resource.

Referring to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> of denying the authorization request. In some embodiments, act <NUM> comprises, based at least on determining that the credential is configured for access to the second protected resource (i.e., "Yes" from act <NUM>), and when the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs (i.e., "No" from act <NUM>), denying the authorization request. In some embodiments, method <NUM> also comprises determining that no exception applies (i.e., act <NUM>) prior to reaching act <NUM>. Technical effects of denying the authorization request in act <NUM> include preventing the origin protected resource from being able to initiate a communications session with the target protected resource. Additionally, technical effects of denying the authorization request in act <NUM> include preventing a lateral traversal from origin protected resource to a target protected resource, since that origin protected resource is outside of a subset of resources to which the target protected resource belongs. As a result, technical effects of denying the authorization request in act <NUM> include preventing escalation of privilege attacks.

Referring to <FIG>, in example 300b the capability determination component <NUM> determines in act <NUM> that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>). Further, in example 300b the subset membership component <NUM> determines in act <NUM> that protected resource 105a is outside of the subset of resources to which protected resource 103a belongs, and that the origin protected resource is thus outside of the target protected resource's subset (i.e., "No" from act <NUM>). Thus, act <NUM> results in a determination of a denial of access to protected resource 103a. As a result, and as shown in <FIG>, method <NUM> proceeds to act <NUM> of denying the authorization request by the denial component <NUM>. For example, in <FIG>, at time (<NUM>) the authority <NUM> sends a reply <NUM> to the protected resource 105a over the network <NUM>. As shown, in embodiments, the reply <NUM> comprises a denial <NUM>, such as a message, an error code, etc. Here, operation of the lateral traversal prevention component <NUM> results in an access denial determination, even though the credential <NUM> would otherwise authorize access to protected resource 103a. Thus, as a technical effect, a lateral traversal from subset <NUM> to subset <NUM>, and a potential privilege escalation, has been prevented.

Referring to <FIG>, in example 300c the capability determination component <NUM> determines in act <NUM> that credential <NUM> is configured for access to protected resource 103a (i.e., "Yes" from act <NUM>). Further, in example 300c the subset membership component <NUM> determines in act <NUM> that protected resource <NUM> is outside of the subset of resources to which protected resource 103a belongs, and that the origin protected resource is thus outside of the target protected resource's subset (i.e., "No" from act <NUM>). Thus, act <NUM> results in a determination of a denial of access to protected resource 103a. As a result, and as shown in <FIG>, method <NUM> proceeds to act <NUM> of denying the authorization request by the denial component <NUM>. For example, in <FIG>, at time (<NUM>) the authority <NUM> sends a reply <NUM> to the protected resource <NUM> over the network <NUM>. As shown, in embodiments, the reply <NUM> comprises a denial <NUM>, such as a message, an error code, etc. Here, operation of the lateral traversal prevention component <NUM> results in an access denial determination, even though the credential <NUM> would otherwise authorize access to protected resource 103a. Thus, as a technical effect, a lateral traversal to subset <NUM> from a resource outside of any subset, and a potential privilege escalation, has been prevented.

In some embodiments, the authority <NUM> also logs the denial of the authorization request, such as into a log file stored in system memory on a computer readable media. This can include logging one or more of the credential, the first protected resource, and the second protected resource. Thus, in some embodiments, method <NUM> further comprises logging denial of the authorization request, including logging the credential, the first protected resource, and the second protected resource. This has a technical effect of providing documentary evidence of an attempted lateral traversal.

In some embodiments, in addition to denying the authorization request at act <NUM>, method <NUM> also comprises configuring a network to deny network communications from the first protected resource to the second protected resource. For example, embodiments may configure a network firewall service to deny communications between the first protected resource to the second protected resource, configure a network tunneling service to deny the establishment of a network tunnel (e.g., an IP Security tunnel) between the first protected resource to the second protected resource, and the like. In embodiments, this has a technical effect of preventing the communication of network packets from the origin protected resource to the target protected resource. Additionally, this prevents a malicious party from attempting to exploit software vulnerabilities at the target protected resource.

Accordingly, the embodiments described herein confine lateral traversal within a computer network based on grouping a plurality of protected resources (e.g., computer systems, services, etc.) into one or more subsets of resources. Then, for at least one protected resource that is a target of an access request, the embodiments described herein configure an authority to enforce a policy that authorizes a request for access to the target protected resource only when the access request originates from an origin protected resource that is in a same subset as the target protected resource. By grouping protected resources into subsets, and by enforcing policies that restrict access across subsets, the embodiments described herein limit the lateral traversal potential of a compromised credential. This has technical effects of limiting lateral traversal to resources within the same subset as a compromised resource, and confining lateral traversal to resources within that subset. This, in turn, improves system security, by limiting the scope of protected resources that a malicious party is capable of reaching and compromising within a computer network.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, or the order of the acts described above.

Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer system that includes computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and/or data structures are computer storage media. Computer-readable media that carry computer-executable instructions and/or data structures are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media are physical storage media that store computer-executable instructions and/or data structures. Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives ("SSDs"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention.

Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems.

A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("laaS"). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

Some embodiments, such as a cloud computing environment, may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, virtual machines emulate an operational computing system, supporting an operating system and perhaps one or more other applications as well. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines. The hypervisor also provides proper isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources including processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

Claim 1:
A method (<NUM>), implemented at a computer system (<NUM>) that includes a processor, for confining lateral traversal within a computer network, the method comprising:
receiving (<NUM>) an authorization request (<NUM>, <NUM>) that includes (a) an authentication token (<NUM>, <NUM>) that identifies a credential (<NUM>) and a first protected resource (103n, 105a) within the computer network, and (b) an identifier of a second protected resource (103a) within the computer network for which authorization is requested;
determining (<NUM>), based on a capability (<NUM>) of the credential, whether or not the credential is configured for access to the second protected resource;
identifying (<NUM>) a lateral traversal policy (<NUM>) associated with the second protected resource, the lateral traversal policy constraining access to the second protected resource to only resources within the computer network that belong to a particular subset of resources (<NUM>) to which the second protected resource belongs;
determining (<NUM>) whether or not the first protected resource belongs to the particular subset of resources to which the second protected resource belongs; and
based at least on determining that the credential is configured for access to the second protected resource, performing (<NUM>) one of:
when the first protected resource is determined to belong to the particular subset of resources to which the second protected resource belongs, issuing (<NUM>) an authorization token (<NUM>) that authorizes the credential to access the second protected resource via the first protected resource; or
when the first protected resource is determined to be outside the particular subset of resources to which the second protected resource belongs, denying (<NUM>) the authorization request.