Automatic just in time access

Abstract

A method for facilitating Just in Time (JIT) access, by a user (52), to a resource (46) in a computer network includes identifying, by a processor (41), an attempt by the user (52) to access the resource (46), in response to identifying the attempt, evaluating, by the processor (41), whether one or more predefined conditions for providing the JIT access are satisfied, and provided the conditions are satisfied, without receiving approval of the JIT access from any other user, executing one or more predefined actions such that the JIT access is provided, or provided the conditions are not satisfied, denying the JIT access. Other embodiments are also described.

Description

[0001] AUTOMATIC JUST IN TIME ACCESS

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] The present application claims priority from US Provisional Application 63 / 656,638, filed June 6, 2024, entitled "Automatic inline just in time access," whose disclosure is incorporated herein by reference, and US Provisional Application 63 / 680,650, filed August 8, 2024, entitled "Automatic inline just in time access," whose disclosure is incorporated herein by reference.

[0004] FIELD OF EMBODIMENTS OF THE INVENTION

[0005] Embodiments of the present invention related to computer network security, and particularly to Just in Time (JIT) access for facilitating such security.

[0006] BACKGROUND

[0007] Just in Time (JIT) access is a security and operational approach that grants users or systems temporary, time-limited access to resources (also referred to herein as "assets") only when it is needed, rather than providing continuous or standing permissions. This method minimizes the attack surface by reducing the window of opportunity for unauthorized access, thereby enhancing overall security. JIT access is commonly used in environments where sensitive data or critical systems require strict access controls, such as cloud infrastructure, privileged account management, and software development pipelines. By leveraging automated workflows and approval mechanisms, JIT access ensures that permissions are granted only for the duration and scope necessary to complete specific tasks, supporting both compliance requirements and operational efficiency.

[0008] SUMMARY

[0009] There is provided, in accordance with some embodiments of the present invention, a system for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network. The system includes at least one memory configured to store program instructions and at least one processor. The processor is configured to execute the program instructions so as to identify an attempt by the user to access the resource, to evaluate, in response to identifying the attempt, whether one or more predefined conditions for providing the JIT access are satisfied, to execute one or more predefined actions such that the JIT access is provided, provided the conditions are satisfied, without receiving approval of the JIT access from any other user, or to deny the JIT access, provided the conditions are not satisfied.

[0010] There is further provided, in accordance with some embodiments of the present invention, a system for terminating access, by a user, to a resource in a computer network. The system includes at least one memory configured to store program instructions and at least one processor. The processor is configured to execute the program instructions so as to receive, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session, to evaluate, using an artificial-intelligence agent, whether the access is justified, based on the screenshots, and to terminate the access in response to deciding that the access is not justified.

[0011] There is further provided, in accordance with some embodiments of the present invention, a method for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network. The method includes identifying, by a processor, an attempt by the user to access the resource. The method further includes, in response to identifying the attempt, evaluating, by the processor, whether one or more predefined conditions for providing the JIT access are satisfied. The method further includes, provided the conditions are satisfied, without receiving approval of the JIT access from any other user, executing one or more predefined actions such that the JIT access is provided, or provided the conditions are not satisfied, denying the JIT access.

[0012] In some embodiments, executing the predefined actions includes executing the predefined actions such that the JIT access is provided during the attempt.

[0013] In some embodiments, executing the predefined actions includes executing the predefined actions such that the JIT access is provided during a subsequent attempt by the user to access the resource.

[0014] In some embodiments, the conditions include performance of step-up authentication by the user.

[0015] In some embodiments, the actions include enabling an account of the user on a directory that services the resource.

[0016] In some embodiments, denying the JIT access includes denying the JIT access by disabling an account of the user on a directory that services the resource.

[0017] In some embodiments, executing the actions includes executing the actions such that the JIT access is subject to a time restriction.

[0018] In some embodiments, evaluating whether the conditions are satisfied includes evaluating whether the conditions are satisfied using an artificial-intelligence agent.

[0019] In some embodiments, the artificial -intelligence agent includes a Large Language Model.

[0020] In some embodiments, the conditions include submission, by the user, of a valid reason for needing the access.

[0021] In some embodiments, evaluating whether the conditions are satisfied includes evaluating whether the conditions are satisfied via a heuristic analysis.

[0022] In some embodiments, evaluating whether the conditions are satisfied includes evaluating whether the conditions are satisfied by comparing historical activity of the user that was approved with an activity for which the access is required.

[0023] In some embodiments, the method further includes deriving the historical activity from a change -request ticket.

[0024] In some embodiments, identifying the attempt includes identifying the attempt in response to receiving a message forwarded from a directory server hosting a directory that services the resource.

[0025] In some embodiments, a group membership query, which is directed to a directory that services the resource, is generated in response to the attempt, and identifying the attempt includes identifying the attempt in response to receiving the group membership query or a response to the group membership query.

[0026] In some embodiments, identifying the attempt includes identifying the attempt in response to receiving a log entry recording the attempt.

[0027] In some embodiments, a query for entitlements or attributes of the user is generated in response to the attempt, and identifying the attempt includes identifying the attempt in response to receiving the query or a response to the query.

[0028] In some embodiments, identifying the attempt includes identifying the attempt in response to a session monitor detecting the attempt.

[0029] In some embodiments, the session monitor includes an agent running on a device of the user.

[0030] In some embodiments, the session monitor includes an application associated with the resource.

[0031] In some embodiments, the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

[0032] In some embodiments, identifying the attempt includes identifying the attempt in response to receiving an authentication request generated in response to the attempt and directed to a directory that services the resource.

[0033] In some embodiments, the method further includes communicating the authentication request to the directory after executing the actions, such that the directory handles the authentication request.

[0034] In some embodiments, communicating the authentication request to the directory includes communicating the authentication request to the directory following a predefined amount of time after executing the actions, such that the actions take effect before the directory receives the authentication request.

[0035] In some embodiments, the method further includes verifying that the actions took effect prior to communicating the authentication request to the directory.

[0036] In some embodiments, an authentication request, which is directed to a directory that services the resource, is generated in response to the attempt, and identifying the attempt includes identifying the attempt in response to receiving an authentication response generated by the directory in response to the authentication request.

[0037] In some embodiments, the actions include modifying the authentication response to provide the JIT access and returning the modified authentication response.

[0038] In some embodiments, modifying the authentication response includes changing the authentication response from a denial of the access to an allowance of the access.

[0039] In some embodiments, modifying the authentication response includes modifying authorization data for the user embedded within the authentication response.

[0040] In some embodiments, the actions include: generating an alternate authentication response that provides the access, and returning the alternate authentication response instead of the authentication response.

[0041] In some embodiments, the actions include modifying permissions of the user on a directory that services the resource. In some embodiments, the actions further include syncing the modification of the permissions across multiple instances of the directory.

[0042] In some embodiments, the actions include modifying the permissions of the user by adding the user to a security group.

[0043] In some embodiments, the predefined conditions and actions belong to a predefined JIT- access policy.

[0044] In some embodiments, the method further includes automatically recommending changes to the JIT-access policy based on historical access information.

[0045] In some embodiments, the JIT-access policy specifies a standing level of access for the user, and the method further includes: automatically classifying entitlements of the user; and defining the standing level of access based on the classified entitlements.

[0046] There is further provided, in accordance with some embodiments of the present invention, a method for terminating access, by a user, to a resource in a computer network. The method includes receiving by a processor, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session, using an artificial-intelligence agent, evaluating whether the access is justified, based on the screenshots, and in response to deciding that the access is not justified, terminating the access.

[0047] In some embodiments, the artificial -intelligence agent includes a Large Language Model.

[0048] In some embodiments, the session monitor includes an agent running on a device of the user.

[0049] In some embodiments, the session monitor includes an application associated with the resource.

[0050] In some embodiments, the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

[0051] In some embodiments, evaluating whether the access is justified includes evaluating whether the access is justified by comparing a reason for needing the access, which was submitted by the user, with current activity of the user as derived from the screenshots.

[0052] In some embodiments, terminating the access includes terminating the access by instructing the session monitor to terminate the access.

[0053] In some embodiments, the method further includes injecting an interactive element into the session, and evaluating whether the access is justified includes evaluating whether the access is justified based on input provided, by the user, via the interactive element.

[0054] In some embodiments, the interactive element includes a chatbot.

[0055] There is further provided, in accordance with some embodiments of the present invention, a computer software product for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network, the computer software product including a tangible non-transitory computer- readable medium in which program instructions are stored. The instructions, when read by at least one processor, cause the processor to identify an attempt by the user to access the resource, to evaluate, in response to identifying the attempt, whether one or more predefined conditions for providing the JIT access are satisfied, and to execute one or more predefined actions such that the JIT access is provided, provided the conditions are satisfied, without receiving approval of the JIT access from any other user, or to deny the JIT access provided the conditions are not satisfied.

[0056] There is further provided, in accordance with some embodiments of the present invention, a computer software product for terminating access, by a user, to a resource in a computer network, the computer software product including a tangible non-transitory computer-readable medium in which program instructions are stored. The instructions, when read by at least one processor, cause the processor to receive, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session, to evaluate whether the access is justified, using an artificial-intelligence agent, based on the screenshots, and to terminate the access in response to deciding that the access is not justified.

[0057] The present invention will be more fully understood from the following detailed description of embodiments thereof, taken together with the drawings, in which:

[0058] BRIEF DESCRIPTION OF THE DRAWINGS

[0059] Figure 1 is a schematic illustration of a JIT access system, in accordance with some embodiments of the present invention;

[0060] Figures 2A, 2B, and 2C show respective modes for a session monitor during interaction of a user with a resource, in accordance with some embodiments of the present invention;

[0061] Figure 3 shows an example flow of traffic for a policy enforcement, in accordance with some embodiments of the present invention;

[0062] Figure 4 shows an example use of artificial intelligence to enforce a policy, in accordance with some embodiments of the present invention; and Figure 5 is a schematic illustration of screenshots of a display during a session, in accordance with some embodiments of the present invention.

[0063] DETAILED DESCRIPTION

[0064] OVERVIEW

[0065] The implementation of a Just in Time (JIT) access policy across an organization presents significant operational challenges, primarily due to the additional administrative overhead imposed on routine activities. The necessity for approval processes, which are not always instantaneous, combined with the complexity of access request procedures, can result in delays to users' workflows. Consequently, many organizations elect to restrict the application of JIT access to a limited group of privileged users, rather than enforcing it organization-wide.

[0066] To address this challenge, embodiments of the present invention provide an automated inline Just in Time (JIT) access solution. Advantageously, using this solution, the user does not need to submit a JIT access request, but rather, the mechanism for deciding whether to provide JIT access is triggered merely by the user's attempt to access the resource. Furthermore, in some embodiments, access is granted inline, meaning that a real-time policy decision regarding access is rendered without delay, typically prior to the completion of the usual authentication request. Moreover, access can be provided without additional human involvement.

[0067] More specifically, a system is provided for facilitating Just in Time (JIT) access to one or more resources, such as a web application or a shared directory, in a computer network, such as a local area network or a cloud network (e.g., belonging to a cloud-computing platform). The system includes one or more processors including, for example, the processor of a directory server, which hosts a directory servicing resources in the network. The processors are configured to cooperatively perform the functionality described herein by executing any one or more software modules, such as the modules shown in Fig. 1. Each processor may be embodied as a single processor or as a cooperatively networked or clustered set of processors.

[0068] Upon an attempt by a user, using a client device, to access one of the resources, one of the processors identifies the attempt and, in response thereto, evaluates whether one or more predefined conditions for providing JIT access to the resource are satisfied. In some embodiments, the conditions include performance of step-up authentication by the user.

[0069] Typically, the processor identifies the attempt in response to receiving a message forwarded from the directory server. As noted above, in some embodiments, the processor belongs to the directory server, such that this forwarding is internal to the directory server. In some embodiments, the processor identifies the attempt in response to receiving an authentication request generated, by the client or by the server hosting the resource, in response to the attempt and directed to the directory. Alternatively, the processor identifies the attempt in response to receiving an authentication response generated by the directory in response to the authentication request. Alternatively, a group membership query, which is directed to the directory, is generated (e.g., by the client or by the server hosting the resource) in response to the attempt, and the processor identifies the attempt in response to receiving the group membership query or a response thereto. As yet another alternative, in some embodiments, the processor identifies the attempt in response to receiving a log entry recording the attempt. Alternatively, a query for entitlements or attributes of the user is generated (e.g., by the client or by the server hosting the resource) in response to the attempt, and the processor identifies the attempt in response to receiving the query or a response to the query. As described above, the authentication request or response, the group membership query or response, the log entry, the query for entitlements or attributes, or the response to such a query may be forwarded, to the processor, from the directory server.

[0070] In other embodiments, the processor identifies the attempt in response to a session monitor detecting the attempt. In some such embodiments, the session monitor includes an agent running on the user's device, an application associated with the resource, and / or a proxy situated between the user's device and the server hosting the resource.

[0071] In some embodiments, the processor evaluates whether the conditions are satisfied using an artificial-intelligence agent. In some embodiments, the artificial-intelligence agent includes a Large Language Model (LLM), which typically evaluates whether the conditions are satisfied via a heuristic analysis. For example, in some embodiments, the conditions include submission, by the user, of a valid reason for needing the access, such that the LLM evaluates whether the conditions are satisfied by evaluating whether the user submitted a valid reason. Such a submission may be performed, for example, via an interactive element that the processor displays on the user's device. Alternatively or additionally, the conditions include similarity of the activity for which the access is required - which may be submitted by the user as described above, or automatically derived from characteristics of the access attempt - with historical activity of the user that was approved, which in some embodiments is derived from a change-request ticket. In such embodiments, the LLM evaluates whether the conditions are satisfied by comparing the activity with the historical activity. Subsequently, provided the conditions are satisfied, the processor executes one or more predefined actions such that the JIT access is provided. Advantageously, the processor provides the JIT access without receiving approval of the JIT access from any other user. Rather, the JIT access is provided in response to the conditions (which do not include approval from any other user) being satisfied.

[0072] In some embodiments, the JIT access is subject to a time restriction. For example, in some embodiments, the JIT access is provided for a predefined amount of time, e.g., from the time the JIT access is granted, from the time the user begins to use the resource, or from the time the user performs a predefined activity using the resource. Alternatively or additionally, for example, the JIT access is provided following a predefined delay.

[0073] In some embodiments, the predefined actions are executed such that the JIT access is provided during the identified attempt. Alternatively, the predefined actions are executed such that the JIT access is provided during a subsequent attempt (typically, the next attempt) by the user to access the resource.

[0074] In some embodiments, the actions include enabling the user's account on the directory. Alternatively or additionally, the actions include modifying permissions of the user on the directory (e.g., by adding the user to a security group) along with, optionally, syncing the modification across multiple instances of the directory.

[0075] Typically, for embodiments in which the processor identifies the access attempt in response to receiving an authentication request, the processor communicates the authentication request to the directory after executing the actions, such that the directory handles the authentication request. In some such embodiments, the processor communicates the authentication request to the directory following a predefined amount of time after executing the actions, such that the actions take effect before the directory receives the authentication request. Alternatively or additionally, the processor verifies that the actions took effect (e.g., by polling the directory and / or by checking a log file) prior to communicating the authentication request to the directory.

[0076] For embodiments in which the processor identifies the access attempt in response to receiving an authentication response, the actions, by definition, take effect only after the response is generated by the directory. In some such embodiments, to facilitate providing JIT access during the current attempt (rather than only during a subsequent attempt), the processor modifies the authentication response to provide the JIT access and then returns the modified authentication response to the directory, to the client, or to the server that hosts the resource. For example, in some embodiments, the processor changes the authentication response from a denial of the access to an allowance of the access, and / or modifies authorization data for the user embedded within the authentication response. Alternatively, the processor generates an alternate authentication response that provides the access, either by generating the response de novo or by replaying the authentication request. Subsequently, the processor returns the alternate authentication response, instead of the original authentication response, to the directory, to the client, or to the server that hosts the resource.

[0077] On the other hand, if the conditions are not satisfied, the processor denies the JIT access, e.g., by disabling the user's account on the directory, by dropping the authentication request or response, or by modifying the authentication response to deny the access.

[0078] Typically, the predefined conditions and actions belong to a predefined JIT-access policy. In some embodiments, one of the processors recommends changes to the JIT-access policy based on historical access information. Alternatively or additionally, the JIT-access policy specifies a standing level of access for the user, which the user has in the absence of JIT access. To facilitate this, the processor automatically classifies entitlements of the user, and defines the standing level of access based on the classified entitlements.

[0079] Alternatively or additionally, the processors are configured to terminate a user's access (e.g., JIT access) to a resource after the access to the resource is granted. In particular, one of the processors receives, from a session monitor (e.g., an agent, and application, and / or a proxy, as described above) monitoring the session in which the access takes place, one or more screenshots of the session, such as a video recording of the session including a stream of screenshots. Subsequently, using an artificial-intelligence agent, which in some embodiments includes a Large Language Model, the processor evaluates whether the access is justified, based on the screenshots. In response to deciding that the access is not justified, the processor terminates the access. For example, in some embodiments, the processor instructs the session monitor to terminate the access, and the session monitor then terminates the access, e.g., by instructing the resource to terminate the access or by closing the connection between the client and the resource.

[0080] In some embodiments, the processor injects an interactive element (e.g., including a chatbot) into the session, and then evaluates whether the access is justified based on input provided, by the user, via the interactive element. Alternatively or additionally, the processor evaluates whether the access is justified by comparing a reason for needing the access, which was submitted by the user (e.g., via the interactive element) and, in some embodiments, was validated automatically (e.g., by an LLM as described above) or by a human, with current activity of the user as derived from the screenshots. In particular, if the current activity matches the reason, i.e., if the user appears to be using the resource in the way the user claimed to intend to use the resource, the access is allowed to continue; otherwise, the access is terminated.

[0081] SYSTEM OVERVIEW

[0082] Reference is now made to Fig. 1, which is a schematic illustration of a JIT access system 20, in accordance with some embodiments of the present invention.

[0083] In the example scenario depicted in Fig. 1, a directory 36 (e.g., MICROSOFT ACTIVE DIRECTORY) is executed on a directory server 40, such as a Domain Controller. System 20 comprises a traffic handler 22 and a policy enforcer 38, which are typically software modules executed on directory server 40 or on a separate server. System 20 further comprises an identity governance and administration module 24, an entitlement and access analyzer 26, and a policy manager 28, which are typically software modules executed on a server 42 different from directory server 40.

[0084] When a user 52, using a client 44, attempts to access a resource 46, such as a shared folder or web application, hosted on a server 48, client 44 or server 48 submits an authentication request to directory 36. In some embodiments, directory 36, or another hardware or software component on directory server 40, is configured to forward the authentication request to traffic handler 22. (As described above in the Overview, this forwarding may be internal to directory server 40.) For example, co-assigned US Patent Application Publication 2025 / 0080519, whose disclosure is incorporated herein by reference, describes techniques for forwarding authentication requests from the network layer of directory server 40, such as by using routing software or destination network address translator software. In response to receiving the authentication request, traffic handler 22 forwards the request to policy enforcer 38. Policy enforcer 38 decides, e.g., based on administrator- defined policies provided by policy manager 28, whether to grant JIT access to the user, and enforces the decision, e.g., by changing a setting on directory 36. After traffic handler 22 returns the request to directory 36, the directory generates an authentication response and communicates the response, via traffic handler 22, to the client.

[0085] Typically, directory 36, or another hardware or software component on directory server 40, is also configured to forward other authentication-related communication to traffic handler 22. For example, in some cases, when the user attempts to access the resource, the resource queries directory 36 for the security groups to which the user belongs. This query, known as a group membership query, along with the response thereto, may be forwarded to traffic handler 22.

[0086] Entitlement and access analyzer 26 is configured to recommend changes to the policies based on historical access information provided by traffic handler 22, historical access information and / or user information provided by directory 36, and / or entitlement information provided by identity governance and administration module 24. These recommendations may be output to policy manager 28, to policy enforcer 38, and / or to an administrator.

[0087] Typically, system 20 further comprises one or more session monitors configured to monitor the user's session, in the event JIT access (or conventional access) was granted, to assess whether the user is using resource 46 as expected. In response to the user not using the resource as expected, the session monitors may stop the session, instruct policy enforcer 38 and / or traffic handler 22 to deny future JIT access attempts, and / or show a recording and / or an analysis of the session to the user. Alternatively or additionally, the session monitors are configured to report the user's attempt to access the resource to traffic handler 22 or to policy enforcer 38, in response to which the policy enforcer decides whether to grant the user JIT access to the resource.

[0088] In some embodiments, the session monitors comprise an agent 30 running on the user's device (i.e., on client 44, as shown in Fig. 2A), such as a browser application programming interface or extension. Alternatively or additionally, the session monitors comprise an application 32 associated with resource 46 (as shown in Fig. 2B), such as a software module that interacts with the resource or is part of the resource, a middleware, or client-side software. Alternatively or additionally, the session monitors comprise a proxy 34 situated between the user's device (i.e., client 44) and server 48 (as shown in Fig. 2C), which can log the user's activities on a web server, for example. In some such embodiments, proxy 34 is activated by traffic handler 22 in response to the granting of a JIT access request.

[0089] The modules shown in Fig. 1 are typically software modules executed by one or more processors, which in some embodiments include a processor 41 of directory server 40 and / or a processor of server 42. In other words, each of the processors is configured to execute program instructions stored in one or more memories (including, for example, one or more random-access memories), such as a memory 43 of directory server 40 and / or a memory of server 42, so as to perform the functionality described herein. Each processor may be embodied as a single processor or as a cooperatively networked or clustered set of processors. Typically, the processor comprises a central processing unit (CPU) and / or a Graphics Processing Unit (GPU). Program instructions, including software programs, and / or data are loaded for execution and processing by the CPU and / or GPU. The program instructions and / or data may be downloaded to the processor in electronic form, over a network, for example. Alternatively or additionally, the program instructions and / or data may be provided and / or stored on non-transitory tangible media, such as magnetic, optical, or electronic memory. Such program instructions and / or data, when provided to the processor, produce a machine or special-purpose computer, configured to perform the tasks described herein.

[0090] ENTITLEMENT AND ACCESS ANALYZER

[0091] As described above, entitlement and access analyzer 26 identifies user entitlements (also referred to herein as "privileges") and assesses how these entitlements are being used. To facilitate this functionality, analyzer 26 receives information from multiple source including, for example, traffic handler 22, directory 36, identity governance and administration module 24, authentication and access logs, identity providers, firewalls, and / or third-party identity governance and administration providers. In some embodiments, analyzer 26 is configured to query one or more these sources for the required information.

[0092] Typically, the data collected by analyzer 26 includes information about authentication and access, typically obtained from traffic handler 22 and / or directory 36. Alternatively or additionally, the data includes, for each user, a list of security groups (and / or other groups) the user belongs to, typically obtained from directory 36, a firewall, or another network-security component. Alternatively or additionally, the data includes user roles, user attributes, user privileges within applications, and / or any other form of user entitlements.

[0093] In some embodiments, analyzer 26 learns entitlements based on actual usage data. For example, in response to seeing a user repeatedly authenticating to a particular resource, analyzer 26 may assume that the user is permitted to access the resource. As another example, in response to seeing many users from a particular group authenticating to a particular resource, analyzer 26 may assume that the group gives the users entitlement to access the resource.

[0094] In some embodiments, analyzer 26 is configured to classify resources with respect to the sensitivity of these resources, e.g., in accordance with the tier model. For example, in some embodiments, analyzer 26 computes the sensitivity of a resource based on the security groups that the resource belongs to, as defined on directory 36, and / or based on user annotations associated with such groups. For example, a Domain Controller can be classified as tier 0 (corresponding to highest sensitivity) based on it belonging to the built-in “Domain Controllers” security group. Typically, the classification is performed based on a set of predefined rules.

[0095] Alternatively or additionally, analyzer 26 is configured to classify each user with respect to their entitlements, e.g., based on the classification of the resources to which the user is entitled, and / or based on an analysis of the user's username or the name of a group to which the user belongs. For example, a username such as “bob admin” may indicate that the user to which this username belongs has relatively broad entitlements.

[0096] Alternatively or additionally, analyzer 26 is configured to classify each of the entitlements for any particular user. For example, in some embodiments, analyzer 26 assigns, to each entitlement, a level indicating the sensitivity of the assets to which the entitlement enables access, and an indicator as to whether the entitlement is being used. For example, in some embodiments, analyzer 26 classifies each entitlement as "high-level - not in use," "high-level - in use," or "low- level." This classification can be static, based on security groups for example, or dynamic, based on a machine learning algorithm that analyzes inputs such as security groups, information about computers and users, and authentication activity. For example, access to a KERBEROS service type indicative of a database can be considered high-level access.

[0097] In some embodiments, analyzer 26 is configured to display, on a graphical user interface, the entitlements for any particular user, including the classifications of the entitlements as described above. Alternatively or additionally, analyzer 26 is configured to communicate this information to policy manager 28, which uses the information to define JIT access policies as described below.

[0098] POLICY MANAGER

[0099] In some embodiments, policy manager 28 defines JIT access policies based on the abovedescribed input from entitlement and access analyzer 26. Alternatively or additionally, policy manager 28 comprises an interface via which an administrator can define the policies. As described above, the policies are enforced by policy enforcer 38.

[0100] Each policy specifies, for at least one user and at least one resource (e.g., multiple users and / or multiple resources), the standing level of access (i.e., the level of access in the absence of JIT access) that the user has to the resource. For example, the user can have no access at all. Alternatively, the user can be given some of the user's existing entitlements but not others, based on the classification received from entitlement and access analyzer 26. For example, in some embodiments, the user can be given the "low-level" entitlements but not the "high-level - not in use" entitlements, optionally with at least some (e.g., all) of "high-level - in use" entitlements also granted to the user (e.g., subject to certain conditions being satisfied).

[0101] Each policy further specifies one or more triggers, a trigger being an event that indicates an attempt, by user 52, to access resource 46, and hence triggers an evaluation of whether to provide JIT access (which is a greater level of access than the standing access) to the resource. In some cases, the triggers include the receipt by traffic handler 22 (e.g., via directory 36) of an authentication request or response, a group membership query or response, a log entry regarding an authentication event, or a query for entitlements or attributes of a user. (Examples of attributes include the user's level of entitlement, the name of the user's manager, and the user's phone number.) Alternatively or additionally (e.g., for a resource within a web application), the triggers include the detection, by a session monitor, of the access attempt.

[0102] Each policy further specifies one or more conditions that must be satisfied for JIT access to be granted. Examples of such conditions include the performance of step-up authentication and approval of the access by an automated (e.g., artificial intelligence) system, e.g., via a heuristic analysis. For example, in some embodiments, approval by the automated system is based on one or more conditions on the authentication, user, or server being satisfied. For example, in some embodiments, the approval is based on the user's username, group membership, role, location, and / or organizational unit, and / or on previous approvals of access (e.g., approval of a change ticket). Alternatively or additionally, the approval is based on the destination, the Internet Protocol (IP) address of the client or server, the service or resource to which access is requested, metadata relating to the authentication, the authentication protocol, and / or the hostname. Alternatively or additionally, the approval is based on historical data, such as historical access related to the authentication, e.g., whether this is the first time the user is attempting to access the server. Alternatively or additionally, the approval is based on the time of access, e.g., whether this time is unusual. Alternatively or additionally, the approval is based on the existence of any risk indicators; optionally, a risk score is assigned to the authentication or to any entity participating in the authentication. Alternatively or additionally, the approval is performed by validating a justification for the access submitted by the user.

[0103] Each policy further specifies one or more possible results of the JIT-access evaluation. Example results include the denial or allowance of the authentication, the disabling of the user (also referred to as a disabling of the user's account) in the directory such that the user cannot authenticate to any resource until the user is enabled again, the enabling of the user in the directory such that the user can authenticate (provided JIT access is granted where required), the adding of the user to a group, and the removal of the user from a group. In some embodiments, a sync operation, such as MICROSOFT ACTIVE DIRECTORY replication, is triggered to expedite any of the latter changes. Additional examples include the changing of the response to an authentication request or query to reflect a change in group membership or in another attribute. Additional examples include the requesting of approval from another person or an automated system (e.g., a system using heuristic analysis), the requesting of step-up authentication, and the scheduling of a change in group membership or in another attribute.

[0104] Optionally, the policy also qualifies the result, e.g., by specifying a time limit and / or a delay. For example, the policy may add the user to a group or allow the user access for a predefined amount of time, or maintain access for a predefined amount of time following any activity.

[0105] In some embodiments, the policies are configured entirely manually by an administrator, e.g., via a web interface. In other embodiments, policy manager 28 recommends, to the administrator, an automatically-built policy tailored for the activity in the organization’s environment. A separate policy can be recommended for every privileged user, or group of users.

[0106] For example, in some embodiments, policy manager 28 receives the list of entitlements of each user, with their classifications, from entitlement and access analyzer 26. The policy manager recommends keeping the standing access for the user’s low-level privileges but not the "high-level - not in use" entitlements, optionally with at least some (e.g., all) of "high-level - in use" entitlements also granted to the user (e.g., subject to certain conditions being satisfied).

[0107] Alternatively or additionally, the policy manager recommends conditions for the policy results, such as by recommending that the user be granted access only from one of the user's regular IP addresses, and / or for resources normally used by the user.

[0108] In some embodiments, the policy manager allows creation of multiple JIT policies for a single user. That way, certain entitlements can be granted in certain conditions, and other entitlements can be granted in other conditions.

[0109] TRAFFIC HANDLER

[0110] Traffic handler 22 receives authentication requests and responses, e.g., as described for the traffic -management server described in co-assigned US Patent Application Publication 2025 / 0080519, whose disclosure is incorporated herein by reference. The requests and responses can be in accordance with any suitable authentication protocol. For MICROSOFT ACTIVE DIRECTORY, such protocols include KERBEROS, NETLOGON, Lightweight Directory Access Protocol (LDAP), Lightweight Directory Access Protocol over SSL / TLS (LDAPS), Security Assertion Markup Language (SAME), and OpenlD Connect. In response to parsing these messages, the traffic handler decides how to handle each authentication.

[0111] For example, in some embodiments, when directory 36 receives an authentication request, it forwards the request to traffic handler 22. Then the traffic handler can change the request before returning the request to the directory. The directory then processes the request, generates a response, and forwards the response to the traffic handler, which can then change the response if necessary.

[0112] For example, for a KERBEROS authentication, the traffic handler can receive an AS REQ (request to authenticate) that was forwarded from the directory server. Optionally, a user secret can be extracted by the traffic handler from the directory or a cache to decrypt the AS REQ, and thereby obtain additional data about (e.g., the context of) the request. In some embodiments, the evaluation of the JIT-access policy is triggered at this point. An advantage of this trigger is that if the policy result is a change in the user's ability to access the resource (e.g., a granting of access to the user), the change can occur before the request is processed by the directory, such that the response from the directory can reflect the change (e.g., the response can allow the access).

[0113] In other embodiments, the evaluation of the policy is triggered by the receipt of the authentication response.

[0114] In some such embodiments, the policy result does not affect the current authentication request, but rather, is effective beginning only with the next authentication request. Thus, for example, if the response includes a refusal of the request but the policy result was to allow access, the user will be granted access upon the next authentication attempt.

[0115] Alternatively, the traffic handler facilitates making the policy result effective for the current authentication attempt, even though the response was already generated. For example, in some embodiments, the traffic handler changes the response in accordance with the policy result. For example, the traffic handler may change the response from a refusal of access to an allowance, or vice versa. As another example, the traffic handler may change authorization data for the user (e.g., group membership data for the user) embedded within the response, such as authorization data within a KERBEROS Privilege Attribute Certificate. Alternatively, the traffic handler creates an alternate response (e.g., a KERBEROS AS REP message) in accordance with the policy result (e.g., using the user's credentials), and returns the alternate response, instead of the original response, to the directory or directly to client 44 or server 48. Alternatively, the traffic handler replays the request (i.e., resends the request to the directory, as if the request were from client 44 or server 48), receives anew response, and then relays the new response to the directory or directly to client 44 or server 48.

[0116] Typically, for single sign-on ticket requests and responses, such as KERBEROS TGS REQ and TGS REP messages exchanged during a Ticket Granting Service Exchange, the traffic handler decrypts the message using the server key, which is obtained from the directory, rather than the user key. Additionally, data (e.g., the IP address or name of the user's device) collected during the initial authentication exchange, such as the KERBEROS Authentication Service Exchange during which AS REQ and AS REP messages are exchanged, as well as data collected during the subsequent single sign-on exchange, are used to evaluate whether the conditions of the policy are satisfied.

[0117] For requests and responses in some encrypted protocols such as NETLOGON, the traffic handler decrypts the message using the machine account’s hash, which the traffic handler extracts from directory server 40. Alternatively, the traffic handler infers the content of the response from a log entry pertaining to the authentication request, which was recorded by directory 36. To receive logs from the directory, inspect the logs, and identify the relevant log entries, the traffic handler may use any technique described in co-assigned US Patent 11,792,008, whose disclosure is incorporated herein by reference.

[0118] Alternatively, for some encrypted protocols such as LDAP or LDAPS, man-in-the-middle encryption and decryption is performed, e.g., as described in co-assigned US Patent Application Publication 2025 / 0080519, whose disclosure is incorporated herein by reference.

[0119] POLICY ENFORCER

[0120] Typically, policy enforcer 38 is configured to enable any policy defined by (or using) policy manager 28 and approved by an administrator. For example, in some embodiments, policy enforcer 38 is configured to remove entitlements that are not in accordance with the policy. For example, for a directory such as MICROSOFT ACTIVE DIRECTORY, the policy enforcer may remove the user from a security group. Alternatively, the policy enforcer may remove all entitlements, for example by disabling the user in the directory.

[0121] In some embodiments, a list of removed entitlements is saved, e.g., in an object in directory 36 or in a database. This allows the entitlements to be restored if system 20 is disabled (or is expected to be disabled) or in any other emergency situation.

[0122] Typically, policy enforcer 38 is further configured to enforce the policy. In particular, the enforcement is initiated by the policy trigger, such as the receipt of an authentication request or response by the traffic handler. In response to the trigger, the policy enforcer assesses whether the policy conditions are satisfied, and enforces the appropriate policy result.

[0123] Typically, to facilitate the functionality of policy enforcer 38, the policy enforcer has access to directory 36.

[0124] In some cases, the policy result, which is implemented by policy enforcer 38, specifies a change to directory 36 such as an enabling or disabling of the user, an addition of the user to a group, or a removal of the user from a group. For such cases, provided the policy enforcer is triggered by the receipt of the authentication request (rather than the receipt of the response), there are several possible ways to increase the probability that the change is in effect before the authentication response is generated by the directory. For example, in some embodiments, the change is done on the same directory server 40 to which the request is directed, rather than on another directory server, which would require waiting for a sync operation such as MICROSOFT ACTIVE DIRECTORY replication. Alternatively, the change is done on another directory server, but a sync operation is then triggered. Alternatively, policy enforcer 38 instructs the traffic handler to wait a predetermined amount of time before releasing the request to the directory. Alternatively, policy enforcer 38 instructs the traffic handler to release the request but then check the response, and if the response indicates that the change is not yet in effect, retry or deny the request. Alternatively, policy enforcer 38 instructs the traffic handler to poll directory 36 to validate that the change came into effect, and only then to release the request. Alternatively, the policy enforcer itself polls directory 36, and in response to validating that the change came into effect, instructs the traffic handler to release the request. Alternatively, policy enforcer 38 instructs the traffic handler to release the request only after receiving an indication, e.g., in a log, that the change came into effect. Alternatively, the traffic handler releases the request even without prior confirmation that the change came into effect, but if the change did not come into effect, the traffic handler modifies the response to reflect the change, as described above.

[0125] Alternatively, the JIT-access policy is applied only upon receiving the response from directory. An advantage of applying the policy at this point is that the response may include information not included in the request, which may be used to evaluate whether the conditions for the policy are satisfied.

[0126] In some embodiments, the policy enforcer analyzes actions of the user before and after accessing the resource to see if the user’s access is justified, and whether the user did what they were supposed to do or declared they would do. For a user requesting access to a resource in a web application, the user's actions within the web application can be monitored using a web proxy, this being an example of proxy 34.

[0127] As noted above, a policy trigger can be a query, from an application (e.g., a web application), for the group membership of a user, for example using LDAP. For example, the user may already be authenticated for the application, but may request access to a resource within the application for which a certain group membership is required. In some embodiments, the traffic handler intercepts such queries, e.g., using techniques for intercepting LDAP binds described in co-assigned US Patent Application Publication 2025 / 0080519, whose disclosure is incorporated herein by reference. Advantageously, the policy is then evaluated before the directory sees the query.

[0128] As noted above, after verifying that the conditions for a policy are satisfied, the policy enforcer enforces the policy result, thereby establishing access for the user in the event that the policy conditions are satisfied. For example, the policy enforcer may enable the user's account, or add the user to a security group that gives the user the necessary entitlements. As noted above, to expedite these changes, a sync operation, such as as MICROSOFT ACTIVE DIRECTORY replication, is performed in some embodiments. As further noted above, if the changes were not in effect by the time the authentication response was generated, the policy enforcer may instruct the traffic handler to modify the authentication response to reflect the change or to perform any other action, such as dropping the response, in response to the change.

[0129] SESSION MONITORS

[0130] Reference is now made to Figs. 2A-C, which show respective modes for a session monitor during interaction of a user with a resource 46 (e.g., a web application), in accordance with some embodiments ofthe present invention. As noted above with reference to Fig. 1, the session monitor is available in client mode as agent 30 (Fig. 2A), in application mode as application 32 (Fig. 2B), and / or in proxy mode as proxy 34 (Fig. 2C).

[0131] In some embodiments, a session monitor intercepts, records, and transmits information regarding the user’s activities. In some embodiments, this information includes video recordings and / or screenshots of the display being used by the user, input events (e.g., mouse clicks and movements, keyboard events, and inserted text), textual descriptions of on-screen elements, structured representations of on-screen elements (e.g., in HyperText Markup Language or extensible Markup Language), and / or log data from software involved in the user’s activities.

[0132] The session monitor transmits the information to policy enforcer 38 (Fig. 1), which uses the information to make policy decisions. For example, the policy enforcer may remove permissions or instruct the session monitor to terminate the user's session. Alternatively or additionally, the information may be used for policy enforcement during a subsequent authentication attempt. Alternatively or additionally, based on the information, the policy enforcer may inject, into a user interface of resource 46, an element that facilitates interaction of the user with the JIT-access system. For example, the policy enforcer may inject an alert or an interactive element, such as a chatbot, that allows any relevant person - e.g., the user, a manager or peer of the user, or the owner of the resource for which access is requested - to submit input. Thus, for example, the user may submit a reason for requiring the enhanced privileges and / or other contextual information, the entities involved, and / or risk information.

[0133] Alternatively or additionally, the information is stored persistently for auditing.

[0134] HEURISTIC ANALYSIS

[0135] In some embodiments, policy enforcer 38 is configured to decide whether the policy conditions are satisfied by executing a heuristic analysis engine. In other words, the policy enforcer decides using heuristics that can’t be expressed as a set of rules or conditions. These heuristics may depend on contextual information from the traffic handler.

[0136] For example, in some embodiments, the heuristic analysis engine implements a Large Language Model (LLM). The LLM is prompted with a question of whether to grant access, given the list of policy conditions. In one embodiment, the engine accesses a ticketing system to see preapproved activities, and then evaluates whether any of the pre-approved activities matches the activity for which access is currently being attempted. Interpretation of the ticket can be done by the LLM, another LLM, or any alternate artificial intelligence tool, such as a Natural Language Processing engine, that is trained to recognize the fields and interpret the text in the ticket.

[0137] In some embodiments, the LLM is trained, or fine-tuned, based on tagged access requests, such as manually-approved or rejected IIT access requests. In some embodiments, if access is approved, the user's activity is evaluated post-approval to determine whether the activity is justified, whether the activity corresponds to the reason for the request that was provided by the user, and / or whether the activity matches any change ticket that was approved. This evaluation can be based on monitoring data received from any one or more of the session monitors described above. The monitoring data can be fed into the LLM or into a separate multi-modal model to determine whether access should be approved.

[0138] In some embodiments, the LLM, or a separate multi-modal model (e.g., a classifier), determines whether the access activity is similar to previous access activity by the same user. In some embodiments, the model analyzing the user’s activity identifies risky, forbidden, or malicious behavior, regardless of the user's stated intention or the nature of the approved activity.

[0139] In some embodiments, the policy enforcer maps an authentication request to the required permission level, based on the authentication activity of other users. In particular, the policy enforcer identifies other users who generated identical or similar authentication requests, and in response to a relatively large portion of these users sharing a permission level, the policy enforcer maps the user's authentication request to the permission level. Subsequently, the policy enforcer grants the user only the permissions (or only a subset of the permissions) provided by this permission level.

[0140] EXAMPLES

[0141] Reference is now made to Fig. 3, which shows an example flow of traffic for a policy enforcement, e.g., for KERBEROS authentication, in accordance with some embodiments of the present invention.

[0142] In this example, a user is logged in to client 44 as a regular (non-privileged) user. The user attempts to log in as a privileged user, by entering a username and password. In response thereto, client 44 creates an authentication request, such as a KERBEROS AS REQ, and sends it to directory 36, such as to a MICROSOFT ACTIVE DIRECTORY. However, before the authentication request reaches the directory, a component on directory server 40 (Fig. 1), which may comprise a Domain Controller, forwards the authentication request to traffic handler (TH) 22. The traffic handler then parses the authentication request, and in response thereto, determines that a JIT-access policy needs to be applied. The traffic handler then triggers policy enforcer 38, sending the policy enforcer all relevant details about the authentication request. The policy enforcer reviews the details of the authentication and checks the conditions of the policies previously configured. For example, the policy may require the user to submit a reason for needing the enhanced permissions. Alternatively or additionally, the policy may require that the user provide a reference to a relevant previously-approved change-request ticket, or that the policy enforcer find such a ticket and / or review the user's authentication history with the policy enforcer. For example, if the user is requesting enhanced privileges for the purpose of installing an application, a relevant ticket may refer to a previous installation, by the user, of a similar type of application.

[0143] The policy enforcer identifies that the user is the owner of the privileged account attempting to log in, e.g., in response to the privileged account being tied to the user's email address. The policy enforcer then sends an out-of-band message (e.g., using Short Message Service or an application such as SLACK), which is directed to the user, to the client, requesting the information needed for validating the authentication request. In response to this message, the user provides the information, e.g., by submitting free text describing a reason for needing the enhanced permissions and / or by providing a reference to an approved change-request ticket.

[0144] In some embodiments, in response to receiving the information, the policy enforcer validates the information with a Large Language Model (LLM). For example, in response to receiving a reason and a reference to a relevant historical ticket, the policy enforcer may retrieve the ticket, and then ask the LLM to confirm that the ticket matches the reason, i.e., that the ticket allowed the user to perform the same sort of operation specified in the user's reason. For example, the query may be as follows: “Please find attached a change-request ticket and a reason provided by the user for a login. Do these match?” If the LLM responds that the ticket and the reason match, the policy enforcer determines that the privileged user should be enabled and be granted permissions to the servers specified in the ticket. The list of permissions can be extracted from the ticket with an LLM, or the policy enforcer can extract the list based on a known ticket structure.

[0145] In response to validating the information, the policy enforcer applies the policy result by instructing directory 36 to enable the user and to add the requested permissions, e.g., by adding the user to the specified security group. In response to receiving the instructions, the directory executes the instructions and acknowledges, to the policy enforcer, that the instructions were received. The policy enforcer then schedules an action that will reverse the policy result, e.g., by removing the user from the security group and disabling the user, after a predetermined amount of time. The policy enforcer then instructs the traffic handler to release the request. The traffic handler then releases the request to the directory, which examines and then grants the request.

[0146] Next, the directory sends an authentication response, such as a KERBEROS AS REP, to the client, but the aforementioned component on directory server 40 (Fig. 1) redirects the response to the traffic handler. The traffic handler analyzes the response and determines, in response thereto, that no change is needed to the response. Finally, the traffic handler releases the response to client 44 via directory 36.

[0147] Reference is now made to Fig. 4, which shows an example use of artificial intelligence to enforce a policy, in accordance with some embodiments of the present invention.

[0148] In Fig. 4, a user 52, such as a contractor, who is employed by an organization attempts to access internal resources or confidential information. Advantageously, in such situations, the system intercepts and analyzes interactive sessions, providing supervision and real-time auditing.

[0149] For example, it will be supposed that user 52 attempts to access an internal organization service (e.g., via MICROSOFT Remote Desktop Protocol), which is an instance of resource 46, executed on a server (or "workstation") 48. The traffic handler intercepts the attempt (e.g., via forwarding from the directory) and the policy enforcer requests justification from the user. Policy enforcer 38 then approves the justification, and in accordance with the relevant JIT policy, grants the user access for a predetermined amount of time.

[0150] Subsequently, proxy 34 monitors the user's session with the service and sends the session data to policy enforcer 38. For example, as user 52 uses client 44 during the session, the session monitor may record the display of client 44, protocol data, keyboard interaction, and / or logs, and send this data to the policy enforcer. The policy enforcer analyzes the session data in real-time and / or after the session. In some embodiments, prior to the analysis, the data is pre-processed, e.g., via compression, frame dropping, detecting key events, and / or removing Personally Identifiable Information, by the proxy and / or the policy enforcer.

[0151] In some embodiments, to analyze the session data, the policy enforcer feeds the session data to an Artificial Intelligence (Al) engine 50, which in some embodiments comprises an LLM with vision capabilities. Engine 50 generates a transcript or summary of the user's actions on the supervised system, and then compares the summary to pre-approved scenarios and reasons and checks the summary against the user’s history and permissions. In some embodiments, engine 50 then provides insights or alerts. For example, in real-time, alerts may be displayed to the user via proxy 34, and / or access can be blocked or terminated by the policy enforcer. Alternatively or additionally, engine 50 may produce an aggregated audit report and a text summary with highlights and insights. Alternatively or additionally, in response to analyzing the session data, policy enforcer 38 may instruct the session monitorto perform any suitable action such as allowing access to the resource, blocking access to the resource, or auditing the user's activities.

[0152] Certain regulations mandate that privileged and sensitive access be recorded and stored for auditing and review. The recording and storing tools often utilize an agent (client or server) or a remote-display proxy that records user interactions (e.g., mouse, keyboard, display) or intercepts protocol data (e.g., SSH, HTTP). These solutions typically produce a video recording or textual shell history as artifacts.

[0153] Leveraging the methods discussed herein, entitlement and access analyzer 26 (Fig. 1) can analyze, summarize, annotate, and index each session for more effective auditing, enrich the data by integrating information from other organizational systems, detect anomalies and threats, and / or produce an aggregated timeline of events in the organization, specific systems, or resources. This solution facilitates large-scale, comprehensive auditing and detection capabilities over session recordings, which previously required manual post-event analysis.

[0154] As another example, following an attempt by user 52 to access a privileged account or system, the traffic handler intercepts the access attempt and asks for a justification, e.g., a text input that explains why the user attempted access. A risk assessment system can decide at this point if access should be granted or if the attempt should be elevated or rejected. If access is granted, proxy 34 (and / or any other session monitor) records the session, as described above. Thus, the supervision system can analyze the session, in real-time or after the fact, and in response thereto, can generate alerts, reports, and / or insights, and / or perform mitigations and protections in real-time (such as by denying access or aborting the session).

[0155] For a more detailed example, reference is now made to Fig. 5, which is a schematic illustration of screenshots of a display 54 of client 44 (Fig. 4) during a session, in accordance with some embodiments of the present invention.

[0156] In this example, a user attempts to access a resource on a cloud-computing platform, such as MICROSOFT AZURE. The user’s activity is monitored and recorded by the session monitor. A recording of the user’s actions, represented by the screenshots, is sent to an LLM to be transcribed. The transcript, for example, is as follows:

[0157] "The user is attempting to log in to the platform. They select their account from a list of available accounts, enter their password, and then input a multi-factor authentication (MFA) verification code from their authenticator app. Once logged in, they are prompted to stay signed in but choose not to select that option. Subsequently, they navigate to the portal homepage and use the search bar to look up "Service XYZ." They click on the "Service XYZ" option from the search results, which directs them to the overview page. However, they are met with a notification that they do not have access to the content, displayed with a "No access" icon on the screen."

[0158] The policy enforcer then checks this transcript and compares it to the user’s entitlements. In this case, no action is taken. The transcript is then saved, along with the session recording, for future audits.

[0159] In another example, which was carried out by the present inventors using embodiments of the present invention, a desktop session on a Domain Controller server was recorded. In the session, administrator privileges were added to a domain user via the MICROSOFT ACTIVE DIRECTORY console. During the recording, screenshots were acquired automatically at a preset frame rate, and the frames were individually uploaded and captioned. Finally, an additional request was made to summarize the frames.

[0160] The prompt to the LLM was as follows:

[0161] "You are analyzing a screen recording. Briefly explain the user's actions depicted in each frame."

[0162] The output from the LLM was as follows:

[0163] 1. The user's mouse cursor is hovering over the WIRESHARK application icon, possibly indicating an intention to open the network protocol analyzer.

[0164] 2. The user's mouse cursor is positioned over the WIRESHARK application icon on the desktop, suggesting they may be preparing to launch the program.

[0165] 3. The user is using the WINDOWS search bar to look for "ACTIVE DIRECTORY users and computers" or a related setting or application, as indicated by the typed text "users" and the highlighted search result.

[0166] 4. The user has opened the "ACTIVE DIRECTORY users and computers" management console on a WINDOWS server and is viewing a list of user accounts and security groups within the directory.

[0167] 5. The user has edited the properties of a user account named "mike" within the "ACTIVE DIRECTORY users and computers" console by typing in the first name, last name, and display name fields, and is now ready to apply the changes.

[0168] 6. The user has added the email address "bob.smith@bobsworld.com" to the account properties of a user named "mike" in the "ACTIVE DIRECTORY users and computers" console and is hovering over the "Apply" button to save the update.

[0169] 7. The user has opened a dialog box to select groups to which they want to assign the user account, with the cursor focused on the input field for object names.

[0170] 8. The user has typed "Administrators" into the input field and is about to click "OK" to add the user to the system administrators group.

[0171] 9. The user has altered the "Member Of properties of the user account "mike" by adding the "Administrators" group and is now hovering over the "Apply" button to confirm this membership change.

[0172] 10. The user is viewing the "Users" folder within the "ACTIVE DIRECTORY users and computers" management console on a WINDOWS server, with the user account "mike" selected.

[0173] 11. The user has closed all windows and applications.

[0174] The LLM was then asked to decide whether the user’s actions correspond to their stated reason for access. The prompt was as follows:

[0175] "Decide whether the user’s actions match their stated reason for accessing the system: “I want to add remote desktop access permissions to another user." Decide whether to allow or deny the actions. Finish your response with ALLOW or DENY."

[0176] The output was as follows:

[0177] "Based on the actions described above, it seems that the user’s action of adding “mike” to the “Administrators” group doesn’t match their stated reason, and so the action should be denied. Answer: DENY"

[0178] This example demonstrates the ability of embodiments of the present invention to analyze the user's actions after access to a resource is granted, and, if necessary, to terminate the access. It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof that are not in the prior art, which would occur to persons skilled in the art upon reading the foregoing description.

Claims

CLAIMS1. A system for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network, the system comprising: at least one memory configured to store program instructions; and at least one processor, configured to execute the program instructions so as to: identify an attempt by the user to access the resource, in response to identifying the attempt, evaluate whether one or more predefined conditions for providing the JIT access are satisfied, and provided the conditions are satisfied, without receiving approval of the JIT access from any other user, execute one or more predefined actions such that the JIT access is provided, or provided the conditions are not satisfied, deny the JIT access.

2. A system for terminating access, by a user, to a resource in a computer network, the system comprising: at least one memory configured to store program instructions; and at least one processor, configured to execute the program instructions so as to: receive, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session, using an artificial-intelligence agent, evaluate whether the access is justified, based on the screenshots, and in response to deciding that the access is not justified, terminate the access.

3. A method for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network, the method comprising: identifying, by a processor, an attempt by the user to access the resource; in response to identifying the attempt, evaluating, by the processor, whether one or more predefined conditions for providing the JIT access are satisfied; and provided the conditions are satisfied, without receiving approval of the JIT access from any other user, executing one or more predefined actions such that the JIT access is provided, or provided the conditions are not satisfied, denying the JIT access.

4. The method according to claim 3, wherein executing the predefined actions comprises executing the predefined actions such that the JIT access is provided during the attempt.

5. The method according to claim 3, wherein executing the predefined actions comprisesexecuting the predefined actions such that the JIT access is provided during a subsequent attempt by the user to access the resource.

6. The method according to claim 3, wherein the conditions include performance of step-up authentication by the user.

7. The method according to claim 3, wherein the actions include enabling an account of the user on a directory that services the resource.

8. The method according to claim 3, wherein denying the JIT access comprises denying the JIT access by disabling an account of the user on a directory that services the resource.

9. The method according to claim 3, wherein executing the actions comprises executing the actions such that the JIT access is subject to a time restriction.

10. The method according to any one of claims 3-9, wherein evaluating whether the conditions are satisfied comprises evaluating whether the conditions are satisfied using an artificialintelligence agent.

11. The method according to claim 10, wherein the artificial-intelligence agent includes a Large Language Model.

12. The method according to claim 10, wherein the conditions include submission, by the user, of a valid reason for needing the access.

13. The method according to claim 10, wherein evaluating whether the conditions are satisfied comprises evaluating whether the conditions are satisfied via a heuristic analysis.

14. The method according to claim 10, wherein evaluating whether the conditions are satisfied comprises evaluating whether the conditions are satisfied by comparing historical activity of the user that was approved with an activity for which the access is required.

15. The method according to claim 14, further comprising deriving the historical activity from a change-request ticket.

16. The method according to any one of claims 3-9, wherein identifying the attempt comprises identifying the attempt in response to receiving a message forwarded from a directory server hosting a directory that services the resource.

17. The method according to any one of claims 3-9, wherein a group membership query, which is directed to a directory that services the resource, is generated in response to the attempt, and wherein identifying the attempt comprises identifying the attempt in response to receivingthe group membership query or a response to the group membership query.

18. The method according to any one of claims 3 -9, wherein identifying the attempt comprises identifying the attempt in response to receiving a log entry recording the attempt.

19. The method according to any one of claims 3-9, wherein a query for entitlements or attributes of the user is generated in response to the attempt, and wherein identifying the attempt comprises identifying the attempt in response to receiving the query or a response to the query.

20. The method according to any one of claims 3-9, wherein identifying the attempt comprises identifying the attempt in response to a session monitor detecting the attempt.

21. The method according to claim 20, wherein the session monitor includes an agent running on a device of the user.

22. The method according to claim 20, wherein the session monitor includes an application associated with the resource.

23. The method according to claim 20, wherein the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

24. The method according to any one of claims 3-9, wherein identifying the attempt comprises identifying the attempt in response to receiving an authentication request generated in response to the attempt and directed to a directory that services the resource.

25. The method according to claim 24, further comprising communicating the authentication request to the directory after executing the actions, such that the directory handles the authentication request.

26. The method according to claim 25, wherein communicating the authentication request to the directory comprises communicating the authentication request to the directory following a predefined amount of time after executing the actions, such that the actions take effect before the directory receives the authentication request.

27. The method according to claim 25, further comprising verifying that the actions took effect prior to communicating the authentication request to the directory.

28. The method according to any one of claims 3-9, wherein an authentication request, which is directed to a directory that services the resource, is generated in response to the attempt, andwherein identifying the attempt comprises identifying the attempt in response to receiving an authentication response generated by the directory in response to the authentication request.

29. The method according to claim 28, wherein the actions include modifying the authentication response to provide the JIT access and returning the modified authentication response.

30. The method according to claim 29, wherein modifying the authentication response includes changing the authentication response from a denial of the access to an allowance of the access.

31. The method according to claim 29, wherein modifying the authentication response includes modifying authorization data for the user embedded within the authentication response.

32. The method according to claim 28, wherein the actions include: generating an alternate authentication response that provides the access, and returning the alternate authentication response instead of the authentication response.

33. The method according to any one of claims 3-9, wherein the actions include modifying permissions of the user on a directory that services the resource.

34. The method according to claim 33, wherein the actions further include syncing the modification of the permissions across multiple instances of the directory.

35. The method according to claim 33, wherein the actions include modifying the permissions of the user by adding the user to a security group.

36. The method according to any one of claims 3-9, wherein the predefined conditions and actions belong to a predefined JIT-access policy.

37. The method according to claim 36, further comprising automatically recommending changes to the JIT-access policy based on historical access information.

38. The method according to claim 36, wherein the JIT-access policy specifies a standing level of access for the user, and wherein the method further comprises: automatically classifying entitlements of the user; and defining the standing level of access based on the classified entitlements.

39. A method for terminating access, by a user, to a resource in a computer network, the method comprising: receiving by a processor, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session; using an artificial-intelligence agent, evaluating whether the access is justified, based onthe screenshots; and in response to deciding that the access is not justified, terminating the access.

40. The method according to claim 39, wherein the artificial-intelligence agent includes a Large Language Model.

41. The method according to claim 39, wherein the session monitor includes an agent running on a device of the user.

42. The method according to claim 39, wherein the session monitor includes an application associated with the resource.

43. The method according to claim 39, wherein the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

44. The method according to claim 39, wherein evaluating whether the access is justified comprises evaluating whether the access is justified by comparing a reason for needing the access, which was submitted by the user, with current activity of the user as derived from the screenshots.

45. The method according to claim 39, wherein terminating the access comprises terminating the access by instructing the session monitor to terminate the access.

46. The method according to any one of claims 39-45, further comprising injecting an interactive element into the session, wherein evaluating whether the access is justified comprises evaluating whether the access is justified based on input provided, by the user, via the interactive element.

47. The method according to claim 46, wherein the interactive element includes a chatbot.

48. A computer software product for facilitating Just in Time (JIT) access, by a user, to a resource in a computer network, the computer software product comprising a tangible non- transitory computer-readable medium in which program instructions are stored, which instructions, when read by at least one processor, cause the processor to: identify an attempt by the user to access the resource, in response to identifying the attempt, evaluate whether one or more predefined conditions for providing the JIT access are satisfied, and provided the conditions are satisfied, without receiving approval of the JIT access from any other user, execute one or more predefined actions such that the JIT access is provided, or provided the conditions are not satisfied, deny the JIT access.

49. The computer software product according to claim 48, wherein the instructions cause theprocessor to execute the predefined actions such that the JIT access is provided during the attempt.

50. The computer software product according to claim 48, wherein the instructions cause the processor to execute the predefined actions such that the JIT access is provided during a subsequent attempt by the user to access the resource.

51. The computer software product according to claim 48, wherein the conditions include performance of step-up authentication by the user.

52. The computer software product according to claim 48, wherein the actions include enabling an account of the user on a directory that services the resource.

53. The computer software product according to claim 48, wherein the instructions cause the processor to deny the JIT access by disabling an account of the user on a directory that services the resource.

54. The computer software product according to claim 48, wherein the instructions cause the processor to execute the actions such that the JIT access is subject to a time restriction.

55. The computer software product according to any one of claims 48-54, wherein the instructions cause the processor to evaluate whether the conditions are satisfied using an artificialintelligence agent.

56. The computer software product according to claim 55, wherein the artificial -intelligence agent includes a Large Language Model.

57. The computer software product according to claim 55, wherein the conditions include submission, by the user, of a valid reason for needing the access.

58. The computer software product according to claim 55, wherein the instructions cause the processor to evaluate whether the conditions are satisfied via a heuristic analysis.

59. The computer software product according to claim 55, wherein the instructions cause the processor to evaluate whether the conditions are satisfied by comparing historical activity of the user that was approved with an activity for which the access is required.

60. The computer software product according to claim 59, wherein the instructions further cause the processor to derive the historical activity from a change-request ticket.

61. The computer software product according to any one of claims 48-54, wherein the instructions cause the processor to identify the attempt in response to receiving a message forwarded from a directory server hosting a directory that services the resource.

62. The computer software product according to any one of claims 48-54,wherein a group membership query, which is directed to a directory that services the resource, is generated in response to the attempt, and wherein the instructions cause the processor to identify the attempt in response to receiving the group membership query or a response to the group membership query.

63. The computer software product according to any one of claims 48-54, wherein the instructions cause the processor to identify the attempt in response to receiving a log entry recording the attempt.

64. The computer software product according to any one of claims 48-54, wherein a query for entitlements or attributes of the user is generated in response to the attempt, and wherein the instructions cause the processor to identify the attempt in response to receiving the query or a response to the query.

65. The computer software product according to any one of claims 48-54, wherein the instructions cause the processor to identify the attempt in response to a session monitor detecting the attempt.

66. The computer software product according to claim 65, wherein the session monitor includes an agent running on a device of the user.

67. The computer software product according to claim 65, wherein the session monitor includes an application associated with the resource.

68. The computer software product according to claim 65, wherein the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

69. The computer software product according to any one of claims 48-54, wherein the instructions cause the processor to identify the attempt in response to receiving an authentication request generated in response to the attempt and directed to a directory that services the resource.

70. The computer software product according to claim 69, wherein the instructions further cause the processor to communicate the authentication request to the directory after executing the actions, such that the directory handles the authentication request.

71. The computer software product according to claim 70, wherein the instructions cause the processor to communicate the authentication request to the directory following a predefined amount of time after executing the actions, such that the actions take effect before the directory receives the authentication request.

72. The computer software product according to claim 70, wherein the instructions further cause the processor to verify that the actions took effect prior to communicating the authentication request to the directory.

73. The computer software product according to any one of claims 48-54, wherein an authentication request, which is directed to a directory that services the resource, is generated in response to the attempt, and wherein the instructions cause the processor to identify the attempt in response to receiving an authentication response generated by the directory in response to the authentication request.

74. The computer software product according to claim 73, wherein the actions include modifying the authentication response to provide the JIT access and returning the modified authentication response.

75. The computer software product according to claim 74, wherein modifying the authentication response includes changing the authentication response from a denial of the access to an allowance of the access.

76. The computer software product according to claim 74, wherein modifying the authentication response includes modifying authorization data for the user embedded within the authentication response.

77. The computer software product according to claim 73, wherein the actions include: generating an alternate authentication response that provides the access, and returning the alternate authentication response instead of the authentication response.

78. The computer software product according to any one of claims 48-54, wherein the actions include modifying permissions of the user on a directory that services the resource.

79. The computer software product according to claim 78, wherein the actions further include syncing the modification of the permissions across multiple instances of the directory.

80. The computer software product according to claim 78, wherein the actions include modifying the permissions of the user by adding the user to a security group.

81. The computer software product according to any one of claims 48-54, wherein the predefined conditions and actions belong to a predefined JIT-access policy.

82. The computer software product according to claim 81, wherein the instructions further cause the processor to recommend changes to the JIT-access policy based on historical access information.

83. The computer software product according to claim 81 , wherein the JIT-access policy specifies a standing level of access for the user, and wherein the instructions further cause the processor to: automatically classify entitlements of the user, and define the standing level of access based on the classified entitlements.

84. A computer software product for terminating access, by a user, to a resource in a computer network, the computer software product comprising a tangible non-transitory computer-readable medium in which program instructions are stored, which instructions, when read by at least one processor, cause the processor to: receive, from a session monitor monitoring a session in which the access takes place, one or more screenshots of the session, using an artificial-intelligence agent, evaluate whether the access is justified, based on the screenshots, and in response to deciding that the access is not justified, terminate the access.

85. The computer software product according to claim 84, wherein the artificial -intelligence agent includes a Large Language Model.

86. The computer software product according to claim 84, wherein the session monitor includes an agent running on a device of the user.

87. The computer software product according to claim 84, wherein the session monitor includes an application associated with the resource.

88. The computer software product according to claim 84, wherein the session monitor includes a proxy situated between a device of the user and a server hosting the resource.

89. The computer software product according to claim 84, wherein the instructions cause the processor to evaluate whether the access is justified by comparing a reason for needing the access, which was submitted by the user, with current activity of the user as derived from the screenshots.

90. The computer software product according to claim 84, wherein the instructions cause the processor to terminate the access by instructing the session monitor to terminate the access.

91. The computer software product according to any one of claims 84-90, wherein the instructions further cause the processor to inject an interactive element into the session, and wherein the instructions cause the processor to evaluate whether the access is justified based on input provided, by the user, via the interactive element.

92. The computer software product according to claim 91, wherein the interactive element includes a chatbot.

Images