Protections against security vulnerabilities associated with temporary access tokens

Disclosed embodiments relate to systems and methods for automatically detecting and addressing security risks in code segments. Techniques include identifying a request from a network identity for an action involving a target network resource, wherein the action requires a temporary access token. Techniques further include performing, based on a security policy, at least one of: storing the temporary access token separate from the network identity and providing the network identity with a customized replacement token having an attribute different from the temporary access token; or creating a customized replacement role for the network identity, the customized replacement role having associated permissions that are customized for the network identity based on the request.

BACKGROUND

In modern network-based environments, it is increasingly important for organizations to securely manage access to restricted network resources while maintaining efficiency for users working with the restricted resources. To manage this effectively, organizations often use access tokens which may encapsulate the security identity of users for purposes of granting access to a resource. For example, once a user has provided credentials, such as a username and password, a temporary token may be provided to allow the user to subsequently access to a resource for a limited time or limited purpose.

While the use of temporary access tokens may ensure some level of security within a network, they are not without flaws. Some network environments may have hundreds of valid temporary tokens at any given time, which may make monitoring and tracking the use of the tokens difficult if not impossible. For example, it may be easy to track the use of a single specific access token within a network and detect potentially malicious activity. However, if an attacker gets ahold of a temporary access token, they may be able to use the token to create a second temporary token to access the resource. This may be repeated many times, effectively converting the temporary token into a permanent token for the attacker. The use of these different temporary tokens may be difficult to detect and, accordingly, a breach may not be detected until after damage to the network or organization has been performed.

To address these issues, existing techniques may include manually setting limitations on the authorization server, for example through policies in a role configuration. For example, the usage of a role may be restricted to a specific IP address, etc. Such techniques, however, are inefficient, requiring manual setting of these roles and policies. Further, they are not adaptive to particular requests or users and monitoring these tokens and/or roles in larger network environments may be impractical.

Accordingly, in view of these and other deficiencies in existing techniques, technological solutions are needed for automatically securing the use of temporary access tokens in network environments. Solutions should advantageously allow for monitoring or auditing the use of temporary tokens within a network environment. Some solutions may ensure that if a temporary access token is misappropriated, it cannot be used by an attacker to generate new tokens or otherwise access a restricted resource. Further, effective technological solutions should allow for management of security tokens and/or associated roles dynamically in response to individual user requests.

SUMMARY

The disclosed embodiments describe non-transitory computer readable media, systems, and methods for securing the use of temporary access tokens in network environments. For example, in an embodiment, a non-transitory computer readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for securing the use of temporary access tokens in network environments. The operations may comprise identifying a request from a network identity for an action involving a target network resource, which may require a temporary access token. The operations may further comprise performing, based on a security policy, at least one of storing the temporary access token separate from the network identity and providing the network identity with a customized replacement token having an attribute different from the temporary access token, or creating a customized replacement role for the network identity, the customized replacement role having associated permissions that are customized for the network identity based on the request.

According to a disclosed embodiment, the operations may further comprise monitoring use of the customized replacement token and detecting an anomaly in the monitored use.

According to a disclosed embodiment, the operations may further comprise monitoring use of the customized replacement token and detecting a potentially malicious activity involving the customized replacement token.

According to a disclosed embodiment, the action may include at least one of: accessing the target network resource or obtaining a role for the network identity to use with the network identity.

According to a disclosed embodiment, the operations may further comprise receiving an access request from the network identity to access the target network resource, the access request including the customized replacement token; and asserting the temporary access token to the target network resource on behalf of the network identity.

According to a disclosed embodiment, the temporary access token may be provided to the network identity on a just-in-time basis.

According to a disclosed embodiment, the operations may further comprise dynamically generating the temporary access token in response to the request.

According to a disclosed embodiment, operations may further comprise replacing the temporary access token with a new version of the temporary access token.

According to a disclosed embodiment, the associated permissions of the customized replacement role may include at least one of: a network address restriction on access to the target network resource, or a location-based restriction on access to the target network resource.

According to a disclosed embodiment, the associated permissions of the customized replacement role are determined according to a least-privilege security policy.

According to another disclosed embodiment, there may be a computer-implemented method for securing the use of temporary access tokens in network environments. The method may comprise identifying a request from a network identity for an action involving a target network resource, which may require a temporary access token. The method may further comprise performing, based on a security policy, at least one of storing the temporary access token separate from the network identity and providing the network identity with a customized replacement token having an attribute different from the temporary access token, or creating a customized replacement role for the network identity, the customized replacement role having associated permissions that are customized for the network identity based on the request.

According to a disclosed embodiment, the method may further comprise archiving activity of the network identity using the temporary access token.

According to a disclosed embodiment, the method may further comprise archiving activity of a plurality of network identities using a plurality of temporary access tokens.

According to a disclosed embodiment, the method may further comprise analyzing the archived activity of the plurality of network identities to identify potentially malicious use of the plurality of temporary access tokens.

According to a disclosed embodiment, the analyzing may be based on a trained machine learning technique.

According to a disclosed embodiment, the method may further comprise upon identifying potentially malicious use of a particular of the plurality of temporary access tokens, performing at least one of: disabling the particular temporary access token, revoking the particular temporary access token, generating an alert regarding the particular temporary access token, or monitoring activity involving the particular temporary access token.

According to a disclosed embodiment, the potentially malicious use of the plurality of temporary access tokens may include creating new temporary access tokens.

According to a disclosed embodiment, the potentially malicious use of the plurality of temporary access tokens may include making requests to the target network resource from different network addresses.

According to a disclosed embodiment, the method may be performed by a proxy server configured to intercept communications from the network identity to the target network resource.

According to a disclosed embodiment, the method may be performed by a server common to a network environment of the target network resource.

According to a disclosed embodiment, the method may further comprise generating a replacement role temporary token associated with the replacement role. Generating the replacement role temporary token comprises at least one of: generating the replacement role temporary token based on a token generating algorithm; or transmitting a request to the target network resource to generate the replacement role temporary token.

Aspects of the disclosed embodiments may include tangible computer-readable media that store software instructions that, when executed by one or more processors, are configured for and capable of performing and executing one or more of the methods, operations, and the like consistent with the disclosed embodiments. Also, aspects of the disclosed embodiments may be performed by one or more processors that are configured as special-purpose processor(s) based on software instructions that are programmed with logic and instructions that perform, when executed, one or more operations consistent with the disclosed embodiments.

DETAILED DESCRIPTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosed example embodiments. However, it will be understood by those skilled in the art that the principles of the example embodiments may be practiced without every specific detail. Well-known methods, procedures, and components have not been described in detail so as not to obscure the principles of the example embodiments. Unless explicitly stated, the example methods and processes described herein are not constrained to a particular order or sequence, or constrained to a particular system configuration. Additionally, some of the described embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently.

The techniques for securing the use of temporary access tokens in network environments described herein overcome several technological problems relating to security, efficiency, and functionality in the fields of cybersecurity and network communications. The disclosed embodiments provide techniques for securely and efficiently managing the use of temporary access tokens within a network environment. In some embodiments, a temporary token system may be implemented as a server or agent within the network. The system may be configured to monitor all traffic within a network pertaining to the use of temporary access tokens, such that the activity may be monitored to identify anomalous and/or potentially malicious use. For example, the system may be configured to detect the use of one temporary access token to generate a second temporary access token. If an attacker were able to generate a temporary access token in this manner, it could create a chain of temporary access tokens, effectively allowing for a permanent access token within the network. Moreover, any activity associated with the cascading use of these tokens may be difficult to track and often is not detected until after an attack is complete. Accordingly, the temporary token system may flag the use of one temporary access tokens to generate additional temporary access tokens as potentially malicious. As another example, the temporary token system may detect the use of a temporary access token originating from an unexpected location (e.g., an unexpected source country, an unexpected IP address, etc.), which may indicate the token has been compromised.

Further, the temporary token system may play an active role in the provisioning of temporary access tokens and/or roles associated with those tokens. For example, the temporary token system may act as an intermediary (e.g., as a proxy server, etc.) during the creation of temporary tokens. The temporary token system may replace original tokens generated at a restricted network resource with customized replacement tokens and provide the customized replacement tokens to the requesting entity. Accordingly, tokens that may be used directly with the restricted resource may not be transmitted to the requesting identity, thereby reducing the risk of the tokens being misappropriated. Further, this ensures that all token activity is directed through the temporary token system for monitoring.

As another example, the temporary token system may generate customized replacement roles with additional restrictions over a role that is being requested. For example, use of a temporary token associated with the role may be conditioned based on attributes of the request (e.g., an IP address of the requesting identity, etc.). This may allow more robust and fine-tuned control over roles within a network environment, thereby improving efficiency, security, and/or functionality of the network.

Reference will now be made in detail to the disclosed embodiments, examples of which are illustrated in the accompanying drawings.

FIGS. 1A and 1Billustrate an example network environment100for securing the use of temporary access tokens in network environments, consistent with the disclosed embodiments. Network environment100may include one or more network entities110, one or more target network resources130, and a temporary token system120, as shown inFIG. 1A. Network environment100may represent a network environment that uses temporary tokens for controlling access by network identities to controlled network resources. For example, temporary security credentials may be provided in the form of temporary tokens to network identity110for accessing target network resource130.

The various components may communicate over a network140. Such communications may take place across various types of networks, such as the Internet, a wired Wide Area Network (WAN), a wired Local Area Network (LAN), a wireless WAN (e.g., WiMAX), a wireless LAN (e.g IEEE 802.11, etc.), a mesh network, a mobile/cellular network, an enterprise or private data network, a storage area network, a virtual private network using a public network, a nearfield communications technique (e.g., BLUETOOTH, infrared, etc.), or various other types of network communications. In some embodiments, the communications may take place across two or more of these forms of networks and protocols. While network environment100is shown as a network-based environment, it is understood that the disclosed systems and methods may also be used in a localized system, with one or more of the components communicating directly with each other.

Network identities, such as network identity110, may communicate with a target network resource130through network140. As used herein, a network identity may refer to any identity that may be provided access or that may request access to a secured resource, such as target network resource130. In some embodiments, network identity110may refer to a particular user or account (e.g., data and/or instructions representing an individual or service account). For example, network identity110may include a user112, as shown inFIG. 1A. User112may be associated with one or more credentials for accessing target network resource130. User112may be provided with or may request temporary access tokens for accessing target network resource130.

In some embodiments, network identity110may refer to a specific device, such as client device114shown inFIG. 1A, or an application residing thereon. Client device114may be associated with one or more credentials for accessing target network resource130and may be provided temporary access tokens. In some embodiments, user112may access target network resource130through client device114. Client device114may include any computing device, such as a desktop or laptop computer or a mobile device (e.g., a mobile phone or tablet) with network communications capabilities. Client device114may also include a number of other devices, including wearable devices (smart watches, smart jewelry, implantable devices, fitness trackers, smart clothing, or head-mounted displays, etc.) or IoT devices (e.g., smart home devices, industrial devices, etc.) that may communicate with target network resource130. In some embodiments, network identity110may comprise a virtual machine. For example, network environment100may include a cloud computing platform, such as Amazon Web Services (AWS™) and network identity110may comprise an Elastic Compute Cloud (EC2™) instance, or a similar form of virtual machine. Consistent with the present disclosure, network identity110may refer to other entities, such as a particular software application, a service deployed in network140, or any other entities that may communicate with a target network resource130.

Network identity110may request access to one or more network resources, such as target network resource130. As used herein, a target network resource130may refer to any resource that may be the subject of access requests within a network. Examples of network resources may include SQL servers, databases or data structures holding confidential information, restricted-use applications, operating system directory services, access-restricted cloud-computing resources (e.g., an AWS™ or Azure™ server), sensitive IoT equipment (e.g., physical access control devices, video surveillance equipment, etc.) and/or any other computer-based equipment or software that may be accessible over a network.

In some embodiments, target network resource130may be a privileged resource, such that access to the network resource may be limited or restricted. For example, access to the requested resource may require a privileged credential (e.g., a password, a username, an SSH key, an asymmetric key, a security or access token, etc.). As described above, target network resource130may be configured to provide temporary access tokens to one or more network identities for access to the network resource. As used herein, a temporary access token may be any security object that allows limited access to a restricted network resource. For example, the access may be limited to a particular time (e.g., may expire after a predetermined period of time has elapsed) or for a particular purpose (e.g., may expire after a requested action or series of actions is complete). The temporary access token may be provided as part of a service for requesting temporary access credentials for a privileged resource. For example, the temporary access token may be provided by a web service, such as an AWS Security Token Service (STS™). The temporary access token may comprise information including an identifier, the identity of a network identity (e.g., an account or user), an identifier of an associated session, security credentials for the network identity, privileges of the network identity, and/or other information associated with the network identity and/or network resource.

If access to the target network resource130is granted, the network identity110may be asked to provide the temporary access token to perform actions associated with the network resource130. For example, network identity110may request a temporary access token from target network resource130and may later access target network resource130using the token. In some embodiments, a temporary access token may be associated with a particular role. For example, the role may define a number of privileges or permissions that a network identity associated with the role is authorized to performed. The present disclosure is not limited to any particular type of token or security object. For example, tokens may be JSON Web Tokens (JWT), opaque access tokens, etc.

Network environment100may also include a temporary token system120, as shown inFIG. 1A. Temporary token system120may be configured to perform various network security enhancements associated with temporary tokens for network environment100. For example, temporary token system120may monitor and/or audit temporary token usage within network environment100. Temporary token system120may be configured to analyze the temporary token usage to identify potential malicious activity. In some embodiments, temporary token system120may further be configured to manage and/or enforce temporary tokens, including validating temporary access token requests and/or generating, storing, and/or transmitting temporary access tokens. In some embodiments, temporary token system120may perform control actions, such as blocking access, revoking or suspending temporary access tokens, generating alerts, modifying roles, or various other control actions. Examples of particular processes that may be performed by temporary token system120are described in greater detail below.

Temporary token system120may be implemented in a variety of ways. For example, temporary token system120may be implemented as a separate system configured to monitor and/or control activities within network140. In such embodiments, temporary token system120may include dedicated components such as a memory, processor, server, operating system, etc. for carrying out the processes described below. In other embodiments, temporary token system120may operate as a service within network140for monitoring and/or controlling various aspects of the provisioning and validation of temporary tokens.

In some embodiments, temporary token system120may be implemented as an intermediary between network identity110and target network resource130, as illustrated inFIG. 1B. For example, temporary token system120may be implemented as a proxy server or agent within network environment100. Accordingly, some or all of the communication traffic between network identity110and target resource130may be directed through temporary token system120. In some embodiments, temporary token system120may be a separate server, such as a proxy server configured to monitor and process requests and other communications between network identity110and target network resource130. In some embodiments, temporary token system120may be implemented as a web-based service, such as CyberArk™ Privileged Session Manager (PSM) for Web, or similar services. While temporary token system120is shown inFIG. 1Bas an interface between network identity110and network140, it is understood that temporary token system120may be implemented anywhere in network environment100such that it is functionally located between network identity110and target network resource130. For example, temporary token system120may be implemented as an intermediary server on the server side (e.g., between network140and target network resource130).

Further, in some embodiments, temporary token system120may be deployed on various other elements of network environment100. For example, temporary token system120may be deployed on an endpoint, such as on network identity110. Temporary token system120may be implemented as an agent or executable software application running within an operating system or application of network identity110. Temporary token system120may monitor and/or intercept actions or commands associated with temporary tokens that are executed on client device114. Similarly, temporary token system120may also be deployed as an agent or software application running on a target endpoint resource, such as target network resource130. Accordingly, some or all of the processes or operations performed by temporary token system120may be performed by other entities within network environment100, including target network resource130.

FIG. 2is a block diagram showing an example temporary token system120, consistent with the disclosed embodiments. Consistent with embodiments of the present disclosure, temporary token system120may be a computing device (e.g., a server, etc.) and may include one or more dedicated processors and/or memories. For example, temporary token system120may include a processor (or multiple processors)210, a memory (or multiple memories)220, and/or one or more input/output (I/O) devices230, as shown inFIG. 2.

Processor210may take the form of, but is not limited to, a microprocessor, embedded processor, or the like, or may be integrated in a system on a chip (SoC). Furthermore, according to some embodiments, the processor210may be from the family of processors manufactured by Intel®, AMD®, Qualcomm®, Apple®, NVIDIA®, or the like. The processor210may also be based on the ARM architecture, a mobile processor, or a graphics processing unit, etc. The disclosed embodiments are not limited to any type of processor configured in temporary token system120.

Memory220may include one or more storage devices configured to store instructions used by the processor210to perform functions related to the disclosed embodiments. Memory220may be configured to store software instructions, such as programs, that perform one or more operations when executed by the processor210to securely obtain data, for example, using process600, described in detail below. The disclosed embodiments are not limited to particular software programs or devices configured to perform dedicated tasks. For example, the memory220may store a single program, such as a user-level application, that performs the functions of the disclosed embodiments, or may comprise multiple software programs. Additionally, the processor210may in some embodiments execute one or more programs (or portions thereof) remotely located from temporary token system120. Furthermore, the memory220may include one or more storage devices configured to store data for use by the programs.

I/O devices230may include one or more network adaptors or communication devices and/or interfaces (e.g., WIFI, BLUETOOTH, RFID, NFC, RF, infrared, Ethernet, etc.) to communicate with other machines and devices, such as with other components of network environment100through network140. For example, temporary token system120may use a network adaptor to receive and transmit communications pertaining to temporary access tokens within network environment100. In some embodiments, I/O devices230may also include interface devices for interfacing with a user of temporary token system120. For example, I/O devices230may comprise a display, touchscreen, keyboard, mouse, trackball, touch pad, stylus, printer, or the like, configured to allow a user to interact with temporary token system120.

Temporary token system120may further comprise one or more components for performing various operations of the disclosed embodiments. For example, temporary token system120may include a token validator component222, a role manager component224, and/or a token analysis component226. Token validator component222may comprise instructions for monitoring, validating, and/or enforcing security policies for temporary token usage. For example, where temporary token system120is implemented as a proxy server or service, token validator component may include instructions for monitoring and/or managing token requests. Token validator component222may include instructions for performing some or all of process300described in greater detail below with respect toFIG. 3.

Role manager component224may comprise instructions for managing temporary token assignments for particular roles. This may provide an additional layer of security over traditional temporary tokens by providing conditional access enforcement for the temporary tokens. For example, role manager component224may include instructions for creating an on-demand replication of a requested role with a set of use restrictions. Role manager component224may include instructions for performing some or all of the actions associated with temporary token system120in process400described in greater detail below with respect toFIG. 4.

Token analysis component226may comprise instructions for observing and analyzing roles and temporary token logs to detect anomalies and malicious events in temporary token usage. For example, token analysis component226may access and analyze logs and other data associated with temporary token usage in network environment100. Token analysis component226may include instructions for performing some or all of the actions associated with temporary token system120in process500described in greater detail below with respect toFIG. 5.

While token validator component222, role manager component224, and token analysis component226are shown as separate components, in some embodiments they may not be implemented separately within memory220. Further, temporary token system120may not include all of components222,224, and226and may include a subset of these components, depending on how temporary token system120is implemented within network environment100. Further, while temporary token system120is shown as having dedicated processor210and memory220, in some embodiments, temporary token system120itself may be integrated into various other components in network environment100, as described above. For example, processor210and/or memory220may correspond to a processor and memory devices of another component in network environment100, such as network identity110and/or target network resource130. In such embodiments, temporary token system120may be executed as software code, a script, or an application within these network entities.

FIG. 3is a block flow diagram illustrating an example process300for validating tokens within a network environment, consistent with the disclosed embodiments. Process300may provide visibility, control, and/or enforcement capabilities in a network environment involving the use of temporary tokens. In some embodiments, temporary token system120may be implemented as a proxy server or service to enable process300, as described above. For example, temporary token system120may be a full proxy which audits and monitors all communications between network identity110and target network resource130, including requests containing temporary access tokens or requests for creation of temporary access tokens. It is understood, however, that temporary token system120may be implemented in various other forms, as described above. In some embodiments, process300may be implemented such that it occurs transparently with respect to network identity110and/or target network resource130. In other words, process300may appear to one or both of network identity110and/or target network resource130as if they are communicating directly with each other and the steps performed by temporary token system120may not be perceptible to these endpoints.

In step302, network identity110may request a temporary access token for accessing target network resource130. In some embodiments, the request may be directed to target network resource130and may be passed through temporary token system120. For example, temporary token system120may be configured to monitor requests and other communications between network identity110. In some embodiments, the request may instead be directed to temporary token system120. For example, temporary token system120may be implemented as a proxy server and network identity110may direct requests to access target network resource130to temporary token system120. The request provided in step302may include information associated with network identity110that may be used to determine whether to authorize the request. For example, the request may include information identifying network identity110, credentials associated with network identity110(e.g., a username, a password, a symmetric or asymmetric key, etc.), a purpose of the request (e.g., an action to be performed, or other information).

As shown by step304inFIG. 3, temporary token system304may monitor traffic between network identity110and target network resource130. Temporary token system120may therefore be configured such that any network traffic pertaining to the use of temporary access tokens passes through or is accessible by temporary token system120. Thus, temporary token system120may monitor every action involving temporary access tokens, including requests to create a temporary access token (e.g., step302), or requests to perform actions involving target network resource130that require a temporary access token (e.g., step314, described below). By monitoring this activity, temporary token system120may detect suspicious events associated with the use of temporary access tokens and block and/or report the activity.

In some embodiments, temporary token system120may identify suspicious activity based on a security policy. As used herein, a security policy may be any set of rules or constraints that define acceptable or expected actions (or prohibited actions) within a network environment. The security policy may define a set of constraints on actions that may be taken by network identities, such as network identity110. The security policy may be stored in a network location that is accessible to temporary token system120. In some embodiments, the security policy may be stored locally to temporary token system120, for example, in memory220. In other embodiments, the security policy may be stored externally, for example in a cloud storage location, on a network database, on a web security platform, on target network resource130, on network identity110, or any other location accessible via network140.

Temporary token system120may identify suspicious activity based on the security policy. Actions that do not comply with the security policy may be identified as suspicious or malicious activity. An example of suspicious activity may include an indication that a temporary token associated with a particular network identity is used by another network identity. For example, a temporary access token created for a particular virtual machine instance (e.g., an EC2™ machine) may be used outside of the machine (e.g., used by a different IP address than the EC2™ machine). This may indicate that the temporary access token has been compromised and thus may be flagged as suspicious or malicious. As another example, a temporary access token that is used to create another temporary access token may be identified as suspicious. For example, if a temporary access token is used to create another temporary access token, this may result in a chain of temporary access tokens, which may effectively create a permanent access token and may make use of the tokens difficult to track.

Temporary token system120may be configured to perform one or more control actions associated with the suspicious activity. For example, temporary token system120may be configured to block access to target network resource130, for example, by revoking or suspending a temporary access token, or denying an access request. In some embodiments, temporary token system120may be configured to generate an alert of the suspicious activity. For example, temporary token system120may alert a system administrator or other entity associated with network environment100.

In accordance with embodiments of the present disclosure, temporary token system120may be configured to actively manage temporary access token traffic and replace temporary access tokens within communications between network identity110and target network resource130. For example, as shown in step306, in response to the request from step302, target network resource130may generate an original token352. Consistent with the disclosed embodiments, original token352may be a temporary access token, as described above. In embodiments where network environment100is an AWS™ environment, original token352may be created by an AWS Security Token Service (STS™). In some embodiments, step306may include authenticating network identity110. For example, if the request provided in step302includes security credentials, step306may include authenticating network identity110based on the security credentials. In other embodiments, target network resource130may generate original token352based on the identity of network identity110or other information associated with the request.

In step308, target network resource130may return original token352. In some embodiments, target network resource130may send original token352directly to temporary token system120(e.g., where temporary token system120is implemented as a proxy server). In other embodiments, target network resource130may direct original token352to network identity110and temporary token system120may intercept original token352.

In step310, temporary token system120may be configured to replace original token352with a customized replacement token354. Customized replacement token354may have at least one attribute that is different from original token352such that customized replacement token354may not be used directly with target network resource130. For example, generating customized replacement token354may comprise replacing or modifying a portion of original token352with customized data (e.g., a random or semi-random string, etc.). In other embodiments, generating customized replacement token354may comprise generating a new, separate token that is independent from original token352. In some embodiments, customized replacement token354may include the same restrictions as original token352. For example, if original token352is valid for a predetermined period of time, customized replacement token354may have the same time restrictions. In other embodiments, customized replacement token354may have different or additional restrictions than original token352. For example, customized replacement token354may be valid for a shorter period of time than original token352or may impose additional use limitations. In some embodiments, the restrictions on customized replacement token354may be determined by one or more security policies. In some embodiments, step310may further comprise storing original access token352separate from network identity110. For example, original token352may be stored in a memory (e.g., memory220), a database, or network location that is accessible to temporary token system120but inaccessible to network identity110. Accordingly, original token352may not have access to network identity110or other entities within network environment100.

In step312, temporary token system120may return customized replacement token354to network identity110. In some embodiments, customized replacement token354may appear as if it were original token352provided by target network resource130. For example, customized replacement token354may mimic one or more structural features or other attributes of original token352such that it may be indistinguishable from a temporary access token issued by target network resource130. Thus, in some embodiments, it may appear to network identity110that it has requested and received a temporary access token directly from target network resource130. In other embodiments, network identity110may communicate directly with temporary token system120.

To access target network resource130, network identity110may return customized replacement token354. For example, in step314, network identity110may request access to target network resource130. The requested access in step314may include any operation requiring privileged access to target network resource130. For example, the request may include a read request in which network identity110requests access to data associated with target network resource130(e.g., stored in a memory or database of target network resource130, etc.). In other embodiments, the request may include a write request, in which network identity110is requesting privileges to modify or write data on target network resource130. Various other forms of requests may also be provided in step314, including those defined by the AWS™ architecture. The request may include customized replacement token354, as shown inFIG. 3. Similar to the request in step302, the request in step314may be directed to target network resource130or may be sent directly to temporary token system120.

In step316, temporary token system120may replace customized replacement token354received from network identity110with original token352. Accordingly, step316may include retrieving original token316from a remote storage location. In some embodiments, step316may further include validating the request, which may comprise verifying that the request includes the correct customized replacement token354, verifying an identity of network identity110, etc. In some embodiments, temporary token system120may monitor the use of customized replacement token354to identify anomalous or potentially malicious activity, as described above. For example, temporary token system120may monitor temporary token activity according to a security policy. In the event that potentially malicious activity is detected, temporary token system120may deny the request sent in step314and/or perform one or more control actions.

If the request is validated in step316, temporary token system120may send original token352to target network resource130in step318. Temporary token system120may include some or all of the information from the request provided in step314. For example, temporary token system120may forward the request received as part of step314and replace customized replacement token354with original token352. In some embodiments, temporary token system120may include additional information in the request (e.g., indicating that the request has been validated at temporary token system120, etc.).

In step320, target network resource130may validate the request based on original token318. If the request is validated, target network resource130may return the requested data (or otherwise allow the requested action) in step322. The data may be returned directly to network identity110or may be returned to temporary token system120and then forwarded to network identity110.

Process300may therefore provide improved security through the implementation of temporary token system120. By replacing original token352with customized replacement token354, only temporary token system120has access to original token352and network identity110has access only to customized replacement token354. Thus, the risk of temporary access tokens being stolen or leaked is reduced because the customized replacement token354cannot be used directly with target network resource130. Further, this ensures that all network traffic involving temporary access tokens may be passed through temporary token system120such that it may be monitored and analyzed for suspicious or anomalous behavior.

In accordance with some embodiments of the present disclosure, temporary token system120may be configured to manage temporary access token assignments and provide conditional access enforcement for the temporary access tokens.FIG. 4is a block flow diagram illustrating an example process400for conditional access enforcement for temporary access tokens, consistent with the disclosed embodiments. As described above, temporary token system120may be functionally located between network identity110and target network resource130. Temporary token system120maybe implemented as a proxy server or agent, or may be implemented as a standalone server or service.

In step402, network identity110may request a temporary access token to access target network resource130. The request may be the same as or similar to the request in step302, described above. In some embodiments, the request may be directed to temporary token system120. In other embodiments, the request may be directed to target network resource130and may be intercepted by temporary token system120. Accordingly, in some embodiments, process400may be performed transparently to network identity110, similar to process300.

In some embodiments, the request in step402may be associated with a particular role452that is defined within network environment100. The role may be associated with a predefined set of permissions or privileges that a user or other network identity may perform with a temporary access token provisioned based on this role. For example, where network environment100is configured according to the AWS EC2™ service, role452may correspond to an Identity and Access Management (IAM™) Role defined within the service. The request may be a request for a temporary access token for the particular role.

At step404, temporary token system120may verify the temporary access token request with target network resource130. For example, target network resource130may confirm that network identity110has access to role452. In some embodiments, temporary token system120may verify whether network identity110has access to role452based on a set of rules or conditions (e.g., according to a security policy) stored locally to temporary token system120.

If network identity110is authorized for the requested temporary token, in step406, temporary token system120may generate a customized replacement role454. Customized replacement role454may be a replication of requested role452, with a set of conditional use restrictions. In some embodiments the conditional use restrictions may be a limitation on the actions that may be performed using the requested role. Accordingly, temporary token system120may generate customized replacement role454with reduced or limited permissions over those defined in requested role452. In some embodiments, the use restrictions may be conditioned based on information associated with the requester, such as the requester's source country, IP address, user agent, or other information included in an access request. The conditions may apply to all permissions within customized replacement role454, or may apply to individual permissions defined in the role.

In some embodiments, when generating customized replacement role454, temporary token system120may determine which use restrictions to apply based on information included in the request. For example, based on the requester's source country, IP address, user agent, or other information included in an access request, temporary token system120may determine which restrictions to apply. Therefore, the customized replacement role454may be determined dynamically such that it is unique to the individual request. In some embodiments, temporary token system120may determine which use restrictions to apply based on a security policy, which may be defined by an organization associated with target network resource130.

As an illustrative example, where network100corresponds to an AWS EC2™ environment, network identity110may request a role named “EC2admin,” which may provide full permissions for the EC2™ service. For example, a user assuming the EC2admin role may have access to create, delete, or change any of the EC2™ virtual machine instances within network environment100. Using temporary token system120, an organization may modify and restrict the permissions associated with the EC2admin role according to a defined security policy (e.g., a conditional access policy). For example, the security policy may define that request from network identities outside a company's IP range may be provided temporary tokens associated with a limited EC2admin role, which may omit some of the privileges of the full EC2admin role. Accordingly, only a network identity requesting the EC2admin role from within the organization's IP range will have access to the full EC2 admin role. While an AWS™ server is used by way of example, it is understood that the disclosed embodiments are not limited to any particular network environment or target network resource.

In step408, temporary token system120may provide customized replacement role454to target network resource130. Target network resource130may store the customized replacement role454for later authentication of network identities. In step410, temporary token system120may generate a temporary token462based on customized replacement role406. In some embodiments, temporary token462may be generated by temporary token system120, as illustrated inFIG. 4. Accordingly, temporary token system120may access at least one temporary token generation algorithm, which, in some embodiments, may be the same temporary token generating algorithm used to generate temporary tokens by target network resource130. In other embodiments, temporary token462may be generated by target network resource130. Accordingly, step410may include transmitting, from temporary token system120to target network resource130, a request for generating temporary token462. Step410may further include receiving temporary token462from target network resource130.

Temporary token462may then be returned to network identity110in step412. As with step312, described above, temporary token462may appear as if it were an original temporary token provided by target network resource130. For example, temporary token462may mimic one or more structural features or other attributes of a token provisioned by target network resource130. Further, temporary token462may not indicate that it is associated with a limited replacement role. Thus, in some embodiments, it may appear to network identity110that it has requested and received a temporary access token directly from target network resource130for the requested role. In other embodiments, network identity110may communicate directly with temporary token system120and may be notified of the limitations associated with customized replacement role454.

At step414, network identity110may request access to target network resource130. The request may include customized replacement token454, as shown inFIG. 4. Notably, unlike with process300, requests in step414may be made directly to target network resource130without being monitored or processed by temporary token system120. Therefore, temporary token system120does not need to be implemented as a full proxy server or agent. At step416, target network resource130may validate the request received through step414based on customized replacement policy454. For example, as described above, validation of the request may be conditioned on information included in the request. For example, if the request originates from an IP address, source country, or user agent that is outside of a predefined list or range, or that differs from the information associated with the original request, target network resource130may deny the request. Otherwise, if the request is validated, target network resource130may return the requested data (or allow the requested action) in step418.

Accordingly, process400may provide improved security through the implementation of temporary token system120. For example, if a temporary token is lost or stolen, the token may blocked if it is not used according to the organization's security policy (e.g., based on an IP address restriction, etc.). Further, process400provides additional flexibility as the network identity110is not required to interact with a proxy server and can communicate directly with target network resource130for access requests using temporary token462.

In some embodiments, temporary token system120may be implemented as a service that may be used to observe and analyze activity logs of network environment100to detect temporary access token usage and malicious actions associated with the tokens.FIG. 5is a block flow diagram illustrating an example process500for detecting malicious events in temporary token usage based on analysis of roles and logs in a network environment, consistent with the disclosed embodiments.

In step502, temporary token system120may request token activity from target network resource130. In some embodiments, the request may be part of a regular audit process. For example, the request may occur automatically at set time intervals (e.g., at a predetermined number of seconds, minutes, hours, days, etc.); as part of a security or maintenance routine, or based on other criteria. In some embodiments, the request may be generated based on an indication of suspicious or malicious activity elsewhere within network environment100. Temporary token system120may be configured to interact with a user, such as user501shown inFIG. 5. User501may access information about the usage of temporary access tokens within network environment100and perform analytics pertaining to the use of these tokens through temporary token system120. For example, user501may interface with temporary token system120through I/O devices230, described above. Accordingly, the request may be triggered by an input of user501.

In response to the request, in step504, temporary token system120may receive a token activity log comprising information about the usage of temporary tokens within network environment100. In some embodiments, the token activity log may comprise all communications and/or activity occurring within network environment100. Alternatively, the activity log may be filtered to include a subset of the communications or activity, such as activity pertaining to the usage of temporary tokens. In some embodiments, the log may be limited to a particular time, such as a predetermined time frame (e.g., the past 24 hours, past week, etc.), activity since the last request was sent, a time frame defined in the request in step502, etc.

In step506, temporary token system120may analyze the token activity log received in step504to detect anomalies and/or potentially malicious activity. For example, such activity may be detected where a temporary access token created for one network identity (e.g. a particular EC2™ machine) is used by another network identity (e.g., by an entity having a different IP address than the EC2™ machine). As another example, the suspicious activity may be based on the creation of another temporary token using a temporary token, as described above. Suspicious activity may also be detected based on a source country, an IP address, a user-agent, or other information associated with a request. In some embodiments, a security policy may define which activity is suspicious and temporary token system120may compare the activity in the activity log to the security policy. In some embodiments, analysis of the activity log may be guided by user501. For example, user501may provide input through I/O devices230and may guide some or all of the analysis.

Consistent with some aspects of the present disclosure, analysis of the activity log may be based on a trained machine learning process. For example, a set of activity logs containing temporary token usage in a network, along with identifications of activity or activity logs known to be associated with malicious activity, may be input into a machine learning model as training data. The resulting trained model may be used to analyze the activity logs to identify suspicious or malicious activity. For example, an artificial neural network configured to identify malicious use of temporary access tokens may be used to analyze the activity logs in step506. Various other machine learning algorithms may be used, including a logistic regression, a linear regression, a regression, a random forest, a K-Nearest Neighbor (KNN) model, a K-Means model, a decision tree, a cox proportional hazards regression model, a Naïve Bayes model, a Support Vector Machines (SVM) model, a gradient boosting algorithm, a deep learning model, or any other form of machine learning model or algorithm.

In some embodiments, temporary token system120may further be configured to perform one or more control actions, as illustrated by step508inFIG. 5. As used herein, a control action may be any action taken in response to a detection of malicious or anomalous temporary token activity. In some embodiments, temporary token system120may generate one or more alerts identifying the detected activity. For example, an alert may be transmitted to an owner of network environment100or target network resource130(e.g., an organization, user501, etc.). The alert may further include recommendations for addressing the problems that have been identified, such as revoking or blocking a temporary access token, updating a security policy, modifying or removing one or more roles associated with the temporary access token, modifying privileges for a user or other network identity, rotating a privileged credential for the user or network identity, or various other actions that may mitigate the detected threat. Additionally, or alternatively, temporary token system120may automatically perform one or more of these control actions based on the identified threat.

In some embodiments, the activity log may include information regarding the configuration of one or more roles within network environment100. Accordingly, step506may further include analyzing the permissions associated with these roles and determining which network identities are associated with the various roles and/or permissions. Temporary token system120may provide recommendations for modifying these roles, for example, by suggesting conditional use restrictions or limited privileges, as described above with respect toFIG. 4. User501may be able to monitor and analyze these roles through temporary token system120.

FIG. 6is a flowchart depicting an example process600for securing the use of temporary access tokens in network environments, consistent with the disclosed embodiments. Process600may be performed by at least one processing device, such as processor210, as described above. It is to be understood that throughout this disclosure, the term “processor” is used as a shorthand for “at least one processor.” In other words, a processor may include one or more structures that perform logic operations whether such structures are collocated, connected, or disbursed. In some embodiments, a non-transitory computer readable medium may contain instructions that when executed by a processor cause the processor to perform process600. Process600is not necessarily limited to the steps shown inFIG. 6, and any steps or processes of the various embodiments described throughout the present disclosure may also be included in process600, including those described above with respect to processes300,400, and500.

At step610, process600may include identifying a request from a network identity for an action involving a target network resource. For example, temporary token system120may identify a request from network identity110to access target network resource130, such as the requests transmitted in steps302and402described above with respect toFIGS. 3 and 4, respectively. Consistent with the present disclosure, the request may require a temporary access token. For example, target network resource130may be a privileged resource such that the action requires use of a temporary access token, as described above. The action may include at least one of: accessing the target network resource130or obtaining a role for the network identity110to use with the network identity110.

In some embodiments, process600may include accessing a security policy associated with usage of temporary access tokens within the network environment. As described above the security policy may be a set of rules or configurations that define acceptable actions within a network environment. In some embodiments the security policy may be directed specifically to temporary access token usage. The processor performing process600may perform one or more actions associated with the temporary access token based on the security policy.

For example, in step620, process600may include storing the temporary access token separate from the network identity110. For example, as described above with respect toFIG. 3, the temporary access token (which may correspond to original token352) may be stored in a memory (e.g., memory220), a database, or network location that is accessible to temporary token system120but inaccessible to network identity110. Accordingly, the temporary access token may not be accessible by network identity110or other entities within the network environment.

In step630, process600may further comprise providing the network identity110with a customized replacement token. For example, temporary token system120may generate customized replacement token354and provide it to network identity110, as described above with respect toFIG. 3. Accordingly, step630may further comprise dynamically generating the customized replacement token in response to the request. In some embodiments, the temporary access token may be provided to the network identity110on a just-in-time basis. For example, temporary token system120may delay providing the customized replacement token to the network identity110until it is needed by the network identity110(e.g., when the network identity110is about to perform the requested action, etc.). As described above, the customized replacement token may have at least one attribute different from the temporary access token such that it may not be used by the network identity to access target network resource130directly. In some embodiments, step630may comprise replacing the temporary access token with a new version of the temporary access token.

In some embodiments, process600may further comprise monitoring use of the customized replacement token. For example, temporary token system120may monitor use of the customized replacement token to detect an anomaly in the monitored use or a potentially malicious activity involving the customized replacement token. Examples of these anomalies and/or potentially malicious uses are described in greater detail above with respect toFIG. 3.

The network identity110may subsequently use the customized replacement token to access the target network resource130. Accordingly, process600may further comprise receiving an access request from the network identity110to access the target network resource130. For example, as described above with respect toFIG. 3, network identity110may provide a request to access target network resource130(step314), which may include the customized replacement token354. Process600may further include asserting the temporary access token to the target network resource130on behalf of the network identity110, as described above with respect to steps316and318.

Based on the security policy, in some embodiments, process600may include creating a customized replacement role for the network identity110, as shown in step640. This may correspond to various steps of process400, described in detail above with respect toFIG. 4. The customized replacement role may have associated permissions that are customized for the network identity110based on the request. For example, the associated permissions of the customized replacement role may include at least one of: a network address restriction on access to the target network resource (e.g., an IP address associated with the network identity), or a location-based restriction on access to the target network resource (e.g., a source country associated with a request). In some embodiments, the associated permissions of the customized replacement role may be determined according to a least-privilege security policy. For example, the least-privilege security policy may be a security policy restricting the permissions of the customized replacement role to only allow access to the information and resources necessary for a legitimate purpose of the requested role. Thus, based on the customized replacement role, the network identity110may be provided only permissions that are essential to perform a requested action or function.

In some embodiments, step640may further comprise generating a replacement role temporary token associated with the replacement role (e.g., temporary token462), as described above with respect toFIG. 4. In some embodiments, the replacement role temporary token may be generated by temporary token system120. Accordingly, step640may comprise generating the replacement role temporary token based on a token generating algorithm, as described above. In other embodiments, the replacement role temporary token may be generated by target network resource130. Accordingly, step640may comprise transmitting a request to the target network resource130to generate the replacement role temporary token.

In some embodiments, process600may further comprise archiving activity of the network identity110using the temporary access token. Accordingly, process600may include one or more steps described above with respect to process500. This may include archiving activity of a plurality of network identities using a plurality of temporary access tokens. In some embodiments, the archiving may be performed by the same entity performing process600(e.g., temporary token system120). In other embodiments, the activity may be archived by another entity within the network environment, such as target network resource130. Accordingly, process600may include requesting the archived activity from target network resource130or another network entity.

Process600may further comprise analyzing the archived activity of the plurality of network identities to identify potentially malicious use of the plurality of temporary access tokens. As described in greater detail above with respect to process500, the analyzing may be based on a trained machine learning technique. For example, a set of archived activity or activity logs containing temporary token usage in a network, along with identifications of activity or activity logs known to be associated with malicious activity, may be input into a machine learning model as training data. The resulting trained model may be used to analyze the activity logs to identify suspicious or malicious activity. The potentially malicious activity may be identified based on various actions or requested actions associated with the temporary tokens. For example, as described above, the potentially malicious use of the plurality of temporary access tokens may include creating new temporary access tokens (e.g., indicating a chain of temporary access token requests) or making requests to the target network resource from different network addresses (e.g., from an IP address outside of an organization's range of IP addresses, etc.).

Process600may further include performing one or more control actions based on the detected malicious activity. For example, process600may further comprise upon identifying potentially malicious use of a particular of the plurality of temporary access tokens, performing at least one of: disabling the particular temporary access token, revoking the particular temporary access token, generating an alert regarding the particular temporary access token, and/or monitoring activity involving the particular temporary access token.

It is to be understood that the disclosed embodiments are not necessarily limited in their application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the examples. The disclosed embodiments are capable of variations, or of being practiced or carried out in various ways.

The disclosed embodiments may be implemented in a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

It is expected that during the life of a patent maturing from this application many relevant virtualization platforms, virtualization platform environments, trusted cloud platform resources, cloud-based assets, protocols, communication networks, security tokens and authentication credentials, and code types will be developed, and the scope of these terms is intended to include all such new technologies a priori.