Patent Description:
Individuals and organizations are increasingly relying on a greater number of different software applications for business as well as personal use. As each software application may require authentication of the user to access the software, it may also be increasingly burdensome on individuals and organizations to maintain separate credentials for each software application. Many software vendors offer single sign-on (SSO) solutions for conveniently accessing these resources. In particular, these solutions provide a uniform way for users to authenticate just once to a trusted system, referred to as an identity provider (IDP), and afterwards be able to access other systems without being prompted for separate authentication. These SSO solutions may mitigate risk for access to third-party applications because user passwords are not stored or managed externally, they reduce password fatigue from different username and password combinations, they reduce time spent re-entering passwords for the same identity, and they reduce information technology (IT) costs due to lower numbers of help desk calls about passwords.

However, user identity has increasingly become a focal point in addressing cybersecurity threats for an organization. For example, in some situations, regular users may become privileged and thus may have access to more sensitive resources. Accordingly, additional security measures may be required, which may include monitoring and recording activities of users that may be audited to provide accountability against malicious behavior. Many current SSO solutions provide users a way to access applications but fail to record the activity of these users in those sessions. To complement these SSO solutions, some additional third-party solutions are available that consist of agent software installed on user endpoints that records all activity of a user, all the time. Patent application <CIT> discloses a method for logging browser session data at a security gateway using an SSL proxy browser extension. This method of continuous storage introduces a significant demand on storage, processing, and transmission requirements for recorded session. These current solutions also significantly impact security for an organization, as recordings may be stored unencrypted and accessible to the third-party vendors that provide the recording solution.

Accordingly, in view of these and other deficiencies in existing techniques, technological solutions are needed for securely and privately auditing web sessions. In particular, solutions should advantageously provide a tailored approach for capturing browser session data, which may reduce the bandwidth requirements for storage and transfer of data. Further, technological solutions should allow recorded browser session data to be stored in a manner that is inaccessible outside of the organization, thereby improving organizational security while enabling auditing of SSO sessions. While a SSO session is used herein by way of example, it is to be understood that the disclosed embodiments may equally be used for any form of secure user session.

A computer-implemented method for securely and privately auditing secured web sessions is disclosed. The method comprises: receiving, at a server from a user endpoint device, encrypted browser session data, wherein the encrypted browser session data comprises browser session data recorded by a browser extension and encrypted by the browser extension using a first auditor key associated with an organization of a user, the browser extension executing on the user endpoint device; storing the encrypted browser session data at the server; receiving, at the server from an auditor endpoint device, an audit request associated with the stored encrypted browser session data; retrieving, by the server, the stored encrypted browser session data based on the audit request; transmitting at least some of the encrypted browser session data from the server to the auditor endpoint device to enable access to the browser session data by the auditor endpoint device, wherein the auditor endpoint device is configured to: access a second auditor key associated with the organization from a key storage device; and decrypt the encrypted browser session data using the second auditor key to enable access to the browser session data.

The computer-implemented method may comprise receiving, from the auditor endpoint device, an indication of a selected subset of the encrypted browser session data.

Transmitting at least some of the encrypted browser session data to the auditor endpoint device may comprise transmitting the selected subset of the encrypted browser session data.

The auditor endpoint device may be configured to display at least one timeline element and wherein the selected subset of the encrypted browser session data may be selected based on an interaction with the timeline element.

The key storage device may be configured to authenticate an auditor identity associated with the audit request.

Accessing the second auditor key from the key storage device by the auditor endpoint device may comprise: generating a transmission key pair comprising a first transmission key and a second transmission key; transmitting the first transmission key to the key storage device, wherein the key storage device may be configured to retrieve an encrypted second auditor key, the encrypted second auditor key having been encrypted by the key storage device using the first transmission key, and transmit the encrypted second auditor key to a specified network location; retrieving the encrypted second auditor key from the specified network location; and decrypting the encrypted second auditor key using the second transmission key.

Accessing the second auditor key from the key storage device may further comprise: generating a transmission identifier; transmitting the transmission identifier to the auditor endpoint device; and selecting the second transmission key based on the transmission identifier.

The auditor endpoint device may be configured to present the first transmission key to the key storage device via a short-range communication.

The key storage device may be configured to encrypt the second auditor key based on an authentication of an auditor identity using the key storage device.

The computer-implemented method may comprise making the first auditor key available to the browser extension based on an indication of the organization.

The browser session data may include at least one screenshot captured by the browser extension.

The browser session data may include metadata associated with the at least one screenshot.

The auditor endpoint device may be configured to display the screenshot after decrypting the encrypted browser session data with at least one marker overlaid on the screenshot.

The at least one marker may indicate a location associated with a recording trigger.

The browser extension may be configured to: detect a recording trigger invoked in response to an action taken by the user during the browser session; and record the screenshot based on the detected recording trigger.

The browser extension may be configured to: detect that the user has navigated to a protected navigation location; and generate a session key based on the detected navigation to the protected navigation location.

Receiving the audit request may include receiving an indication of a selected trigger event.

Transmitting at least some of the encrypted browser session data may include transmitting a subset of the encrypted browser session data associated with the selected trigger event.

Also disclosed is a computer-readable medium including instructions that, when executed by at least one processor, cause the at least one processor to perform the method for securely and privately auditing secured web sessions described above.

The second auditor key may be stored on the key storage device and be inaccessible to the at least one processor.

The disclosed embodiments also describe computer readable media, systems, and methods for securely and privately auditing web sessions. For example, a computer readable medium may include instructions that, when executed by at least one processor, cause the at least one processor to perform operations for securely and privately auditing web sessions, is disclosed. The operations may comprise receiving, from a browser extension executing on a user endpoint device, encrypted browser session data and an encrypted session key. The encrypted browser session data may comprise browser session data recorded by the browser extension and encrypted by the browser extension using a session key; and the encrypted session key may comprise the session key having been encrypted by the browser extension using a first auditor key associated with a tenant. The operations may further comprise storing the encrypted browser session data and the encrypted session key; receiving, from an auditor endpoint device, an audit request associated with the stored encrypted browser session data; retrieving the stored encrypted browser session data and the stored encrypted session key based on the audit request; and transmitting at least some of the encrypted browser session data and the encrypted session key to the auditor endpoint device to enable access to the browser session data by the auditor endpoint device. The auditor endpoint device may be configured to access a second auditor key associated with the tenant from a key storage device; decrypt the encrypted session key using the second auditor key; and decrypt the encrypted browser session data using the decrypted session key to enable access to the browser session data.

The second auditor key may be stored on the key storage device and may be inaccessible to the at least one processor.

The operations may further comprise making the first auditor key available to the browser extension based on an indication of the tenant.

The indication of the tenant may be based on authentication of the user.

The browser extension may be configured to detect that a user has navigated to a protected navigation location; and generate the session key based on the detected navigation to the protected navigation location.

Storing the encrypted browser session data and the encrypted session key may comprise storing the encrypted browser session data and the encrypted session key in a database.

The browser session data may be derived from actions taken by a user during a browser session.

The browser extension may be configured to detect a recording trigger associated with the endpoint device; and record the browser session data based on the detected recording trigger.

The recording trigger may be invoked in response to an action taken by a user during the browser session.

Also described isa computer-implemented method for securely and privately auditing secured web sessions. The method may comprise receiving, from a browser extension executing on a user endpoint device, encrypted browser session data and an encrypted session key. The encrypted browser session data may comprise browser session data recorded by the browser extension and encrypted by the browser extension using a session key; and the encrypted session key may comprise the session key having been encrypted by the browser extension using a first auditor key associated with a tenant. The method may further comprise storing the encrypted browser session data and the encrypted session key; receiving, from an auditor endpoint device, an audit request associated with the stored encrypted browser session data; retrieving the stored encrypted browser session data and the stored encrypted session key based on the audit request; and transmitting at least some of the encrypted browser session data and the encrypted session key to the auditor endpoint device to enable access to the browser session data by the auditor endpoint device. The auditor endpoint device may be configured to access a second auditor key associated with the tenant from a key storage device; decrypt the encrypted session key using the second auditor key; and decrypt the encrypted browser session data using the decrypted session key to enable access to the browser session data.

The method may further comprise receiving, from the auditor endpoint device, an indication of a selected subset of the encrypted browser session data.

The selected subset may be selected based on at least one of: a particular trigger event, a particular user, a particular user session, a range of times, a range of events, a selection of one or more events, a search function, and a filter function.

The key storage device may be a mobile device.

The audit request may be based on an auditor identity navigating to a recording auditing navigation location.

Accessing the second auditor key from the key storage device by the auditor endpoint device may comprise: generating a transmission key pair comprising a first transmission key and a second transmission key; transmitting the first transmission key to the key storage device, wherein the key storage device is configured to: retrieve an encrypted second auditor key, the encrypted second auditor key having been encrypted by the key storage device using the first transmission key and transmit the encrypted second auditor key to a specified network location; retrieving the encrypted second auditor key from the specified network location; and decrypting the encrypted second auditor key using the second transmission key.

Accessing the second auditor key from the key storage device may comprise: generating a transmission identifier; transmitting the transmission identifier to the auditor endpoint device; and selecting the second transmission key based on the transmission identifier.

The short-range communication may include at least one of displaying a machine-readable code encrypting the transmission key or transmitting the transmission key via a short-range communication protocol.

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

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only, and are not restrictive of the disclosed embodiments, as claimed.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate disclosed embodiments and, together with the description, serve to explain the disclosed embodiments. In the drawings:.

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

The techniques for securely establishing secretless and remote native access sessions described herein overcome several technological problems relating to security, efficiency, and functionality in the fields of cybersecurity and remote session monitoring. In particular, the disclosed embodiments provide techniques for securely monitoring and recording user activity on a client endpoint device. As discussed above, many current third-party software agents that record user activity store the recorded activity in an insecure manner. For example, the third-party software may have access to the recorded activity, which may present security issues for the organization. Further, many current solutions consist of agent software installed on user endpoints that record all activity of the user at all times. Accordingly, these existing techniques require expansive storage to capture all of the recorded activity. Moreover, because all activity is recorded, it can be difficult for an auditor wishing to view the recorded data to meaningfully navigate through this vast volume of recorded data.

The disclosed embodiments provide technical solutions to overcome these and other problems with the current techniques. In particular, the disclosed techniques record, transfer and store the recorded user activity in a secure manner. Accordingly, activity of a user may be accessible only to the user's organization (which may be referred to as a "tenant" of the system) and may not be accessible to any third-party servers where the information is stored, thereby improving security for the organization. Further, the disclosed techniques allow for particular sensitive user activities to be recorded, rather than all activities of a user. For example, the user's activity may be monitored using a lightweight browser extension, without the need to install dedicated software agents on the user endpoint device. The browser extension may detect when the user navigates to sensitive network locations and may record only those sensitive sessions. Further, the browser extension may monitor for certain triggers of user activity and record screenshots or other data based on the activity. Accordingly, the disclosed embodiments provide techniques for tailored recording of activity that may be of interest, which may significantly decrease the demand on bandwidth for transferred data as well as storage of the recorded activity. For these, and other reasons that will be apparent to those skilled in the art from the disclosure herein, the disclosed techniques provide improved security, efficiency, and functionality over existing techniques.

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

<FIG> illustrates an example system environment <NUM> for securely and privately auditing web sessions, consistent with the disclosed embodiments. System environment <NUM> may include one or more user endpoint devices <NUM>, one or more auditor endpoint devices <NUM>, one or more key storage devices <NUM>, and one or more servers <NUM>, as shown in <FIG>. System environment <NUM> may represent a system or network environment in which activities of a user <NUM> on user endpoint device <NUM> are recorded and stored on server <NUM>. An auditor <NUM> may then audit these recordings using an auditor endpoint device <NUM>. As described above, the recording, transmission, and storage of the recorded user activity may be performed in a secure manner, such that only user endpoint device <NUM> and auditor endpoint device <NUM> can have access to the recorded activity.

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

User endpoint device <NUM> may be configured such that user <NUM> may access a protected navigation location through a browser or other software executing on user endpoint device <NUM>. As used herein, a protected navigation location may be any network location deemed sensitive. Activity of a user at the network location may be audited to provide increased accountability for the user. For example, a protected navigation location may include a particular URL (or URL domain, etc.), a network location internal to an organization, or any other sensitive network location. User endpoint device <NUM> may include any form of computer-based device or entity through which user <NUM> may access a protected navigation location. For example, user endpoint device <NUM> may be a personal computer (e.g., a desktop or laptop computer), a mobile device (e.g., a mobile phone or tablet), a wearable device (e.g., a smart watch, smart jewelry, implantable device, fitness tracker, smart clothing, head-mounted display, etc.), an loT device (e.g., smart home devices, industrial devices, etc.), or any other device that may be capable of accessing web pages or other network locations. In some embodiments, user endpoint device <NUM> may be a virtual machine (e.g., based on AWS™, Azure™, IBM Cloud™, etc.), container instance (e.g., Docker™ container, Java™ container, Windows Server™ container, etc.), or other virtualized instance. Using the disclosed methods, activity of user <NUM> through user endpoint device <NUM> may be monitored and recorded by a browser extension executing on user endpoint device <NUM>.

User endpoint device <NUM> may communicate with server <NUM> through network <NUM>. For example, user endpoint device <NUM> may transmit recorded activity of user <NUM> to server <NUM>. As described in further detail below, the recorded activity may first be encrypted such that it is inaccessible to server <NUM>, which may be operated by a third party to an organization associated with user <NUM>. Server <NUM> may include any form of remote computing device configured to receive, store, and transmit encrypted browser session data. For example, server <NUM> may be a server configured to store files accessible through a network (e.g., a web server, application server, virtualized server, etc.). Server <NUM> may be implemented as a Software as a Service (SaaS) platform through which software for auditing recorded user activity may be provided to an organization as a web-based service. In some embodiments, server <NUM> may include or access a database <NUM> configured to store recorded user activity (i.e., browser session data).

Auditor endpoint device <NUM> may similarly communicate with server <NUM> through network <NUM>. In particular, an auditor <NUM> may use auditor endpoint device <NUM> to access and view recorded user activity stored on server <NUM>. Auditor endpoint device <NUM> may include any computing device configured to enable a user to access and view data via a remote server. For example, auditor endpoint device may be a personal computer (e.g., a desktop or laptop computer), a mobile device (e.g., a mobile phone or tablet), a wearable device (e.g., a smart watch, smart jewelry, implantable device, fitness tracker, smart clothing, head-mounted display, etc.), an loT device (e.g., smart home devices, industrial devices, etc.), or any other device that may access and display recorded data. In some embodiments, user endpoint device <NUM> may be a virtual machine (e.g., based on AWS™, Azure™, IBM Cloud™, etc.), container instance (e.g., Docker™ container, Java™ container, Windows Server™ container, etc.), or other virtualized instance.

System <NUM> may also include a key storage device <NUM>. Key storage device <NUM> may be any computing device that may be used to store a private auditor key and provide the private auditor key based on an authentication of an identity of auditor <NUM>. For example, key storage device <NUM> may be a mobile phone or other mobile device of auditor <NUM>. Additionally or alternatively, key storage device <NUM> may include a laptop, a tablet, a wearable device (e.g., a smart watch, smart jewelry, implantable device, fitness tracker, smart clothing, head-mounted display, etc.), or any other device that may be used to authenticate auditor <NUM>. In some embodiments, key storage device <NUM> may be a memory device, such as a flash drive, a solid -state drive, a hard drive, or the like. In some embodiments, key storage device <NUM> may not necessarily be a separate device from auditor endpoint device <NUM>. For example key storage device <NUM> may be implemented as a software-based authenticator for securely storing data within auditor endpoint device <NUM>. Various other forms of key storage devices may be used, consistent with the disclosed embodiments. Key storage device <NUM> may be configured to communicate with server <NUM> via network <NUM>. Key storage device <NUM> may further be configured to communicate with auditor endpoint device <NUM>, either through network <NUM>, or through a separate short-range communication, as described further below.

<FIG> is a block diagram showing an example server <NUM>, consistent with the disclosed embodiments. As described above, server <NUM> may be a computing device (e.g., a server, etc.) and may include one or more dedicated processors and/or memories. For example, server <NUM> may include a processor (or multiple processors) <NUM>, and a memory (or multiple memories) <NUM>, as shown in <FIG>.

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

Memory <NUM> may include one or more storage devices configured to store instructions used by the processor <NUM> to perform functions related to server <NUM>. The disclosed embodiments are not limited to particular software programs or devices configured to perform dedicated tasks. For example, the memory <NUM> may store a single program, such as a user-level application, that performs the functions associated with the disclosed embodiments, or may comprise multiple software programs. Additionally, the processor <NUM> may, in some embodiments, execute one or more programs (or portions thereof) remotely located from server <NUM>. Furthermore, memory <NUM> may include one or more storage devices configured to store data for use by the programs. Memory <NUM> may include, but is not limited to a hard drive, a solid state drive, a CD-ROM drive, a peripheral storage device (e.g., an external hard drive, a USB drive, etc.), a network drive, a cloud storage device, or any other storage device.

In some embodiments, memory <NUM> may include a database <NUM> as described above. Database <NUM> may be included on a volatile or non-volatile, magnetic, semiconductor, tape, optical, removable, non-removable, or other type of storage device or tangible or non-transitory computer-readable medium. Database <NUM> may also be part of server <NUM> or separate from server <NUM>. When database <NUM> is not part of server <NUM>, server <NUM> may exchange data with database <NUM> via a communication link. Database <NUM> may include one or more memory devices that store data and instructions used to perform one or more features of the disclosed embodiments. Database <NUM> may include any suitable databases, ranging from small databases hosted on a work station to large databases distributed among data centers. Database <NUM> may also include any combination of one or more databases controlled by memory controller devices (e.g., server(s), etc.) or software. For example, database <NUM> may include document management systems, Microsoft SQL™ databases, SharePoint™ databases, Oracle™ databases, Sybase™ databases, other relational databases, or non-relational databases, such as mongo and others.

<FIG> is a block diagram showing an example endpoint device <NUM>, consistent with the disclosed embodiments. Endpoint device <NUM> may correspond to one or both of user endpoint device <NUM> and auditor endpoint device <NUM>. As shown in <FIG>, endpoint device <NUM> may include a processor (or multiple processors) <NUM>, a memory (or multiple memories) <NUM>, and/or one or more input/output (I/O) devices <NUM>, as shown in <FIG>.

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

Further, similar to memory <NUM>, memory <NUM> may include one or more storage devices configured to store instructions used by the processor <NUM> to perform functions related to endpoint device <NUM>. The disclosed embodiments are not limited to particular software programs or devices configured to perform dedicated tasks. For example, the memory <NUM> may store a single program, such as a user-level application (e.g., a browser), that performs the functions associated with the disclosed embodiments, or may comprise multiple software programs. Additionally, the processor <NUM> may, in some embodiments, execute one or more programs (or portions thereof) remotely located from endpoint device <NUM> (e.g., located on server <NUM>). Furthermore, memory <NUM> may include one or more storage devices configured to store data for use by the programs. Memory <NUM> may include, but is not limited to a hard drive, a solid state drive, a CD-ROM drive, a peripheral storage device (e.g., an external hard drive, a USB drive, etc.), a network drive, a cloud storage device, or any other storage device.

I/O devices <NUM> may include one or more network adaptors or communication devices and/or interfaces (e.g., WIFI, BLUETOOTH, RFID, NFC, RF, infrared, Ethernet, etc.) to communicate with other machines and devices, such as with other components of system environment <NUM> through network <NUM>. For example, endpoint device <NUM> may use a network adaptor to receive and transmit communications pertaining to recorded user activity data within system environment <NUM>. In some embodiments, I/O devices <NUM> may also include interface devices for interfacing with a user of endpoint device <NUM>, such as user <NUM> or <NUM>. For example, I/O devices <NUM> may comprise a display, touchscreen, keyboard, mouse, trackball, touch pad, stylus, printer, or the like, configured to allow a user to interact with endpoint device <NUM>.

<FIG> illustrates an example browser application <NUM> through which activity of a user may be recorded, consistent with the disclosed embodiments. Browser <NUM> may be any application configured to access webpages or other network locations through a network, such as the Internet. While a browser is used by way of example, the disclosed techniques may equally apply to other applications at which a user's activity may be recorded. In some embodiments, browser <NUM> may be a web browser application, such as Google Chrome™, Mozilla Firefox™, Microsoft Edge™, Internet Explorer™, Safari™, or similar applications. Browser <NUM> may execute on user endpoint device <NUM> and may be used by user <NUM> to navigate to various webpages or network locations. In some embodiments, browser <NUM> may include multiple tabs, allowing browser <NUM> to have multiple webpages open at the same time. For example, this may include an active tab <NUM>, which may be associated with a protected navigation location <NUM>, and an inactive tab <NUM>, that may not be displayed.

Browser <NUM> may further include a browser extension <NUM>, which may be a software component executing as part of browser <NUM>. As used herein, a browser extension refers to a relatively small software module or component configured to supplement a browser application. In some embodiments, browser extension <NUM> may interface with browser <NUM> through an application programming interface (API) for browser <NUM>. Browser extension <NUM> may be associated with server <NUM> and may carry out various tasks associated with recording browser session data. For example, browser extension <NUM> may be configured to capture one or more screenshots <NUM> as well as metadata <NUM> associated with activity of a user within protected navigation location <NUM>. These screenshots <NUM> and metadata <NUM>, as well as any other recorded data, may be referred to collectively as "browser session data.

Browser extension <NUM> may be configured to initiate recording of this browser session data when user <NUM> navigates to a sensitive location, such as protected navigation location <NUM>. For example, browser extension <NUM> may be configured to continuously monitor loaded webpages, which may be represented as uniform resource locators (URLs), or other network addresses accessed by user <NUM>. Browser extension <NUM> may be configured to detect network locations designated as being sensitive. In embodiments, browser extension <NUM> may be configured to retrieve configuration information indicating which network locations are designated as sensitive. For example, a tenant or organization may specify particular network locations to be monitored and deemed sensitive. This information may be stored local to browser extension <NUM>, at server <NUM>, or in any other location accessible to browser <NUM>. Accordingly, browser extension <NUM> may access a list of protected navigation locations or protected domains, which may be predetermined or configured by an organization associated with user <NUM>. In some embodiments, protected navigation location <NUM> may include a HyperText Markup Language (HTML) element <NUM>. In some embodiments, HTML element <NUM> may be associated with authentication of user <NUM> (e.g., as a second factor in a multi-factor authentication), as described further below. In some embodiments, navigation to protected navigation location <NUM> may be detected based on detection of HTML element <NUM> by browser extension <NUM>. The recorded browser session data may be captured and transmitted to server <NUM>, as described in further detail below with respect to process <NUM>.

In some embodiments, browser extension <NUM> may be configured to generate or access one or more keys for encrypting recorded browser session data. For example, this may include generating a session key <NUM> associated with a particular recording session. In some embodiments, session key <NUM> may be a symmetric key. Accordingly, in order to generate session key <NUM>, browser extension <NUM> may store, or have access to, one or more encryption algorithms such as Data Encryption Standard (DES), Triple DES (TDES), Advanced Encryption Standard (AES), CAST-<NUM>, Twofish™, Serpent™ or various others. While various keys described herein may be described as either symmetric or public/private key pairs by way of example, it is to be understood that any form of key may be used, depending on the particular application or embodiment.

In some embodiments, browser extension <NUM> may further be configured to access a first auditor key <NUM>. First auditor key <NUM> may be part of an auditor key pair, which may be unique to a particular tenant associated with user <NUM>. Server <NUM> may be associated with multiple tenants and may therefore be used for recording and auditing activity from multiple tenants, which may only be accessible through auditor keys associated with that tenant. In this example, the tenant may refer to an organization to which user <NUM> and auditor <NUM> belong. This auditor key pair may be generated for a particular tenant during an initial set-up phase for the particular tenant. In some embodiments, first auditor key <NUM> may be a public key as part of a private/public key pair.

The first auditor key <NUM> may be accessed in various ways. In some embodiments, first auditor key <NUM> may be hidden within HTML element <NUM>. Accordingly, browser extension <NUM> may detect HTML element <NUM> and look for and extract first auditor key <NUM> from within HTML element <NUM>. While including first auditor key <NUM> in HTML element <NUM> is provided by way of example, various other methods for providing first auditor key <NUM> to browser extension <NUM> may be used. For example, this may include accessing first auditor key <NUM> through a cookie, a token, or any other suitable techniques for providing first auditor key <NUM> to browser extension <NUM> based on navigation to protected navigation location <NUM>.

Once a recording session has been initiated, browser extension <NUM> may record activity of user <NUM>. In some embodiments, this may include recording all activities of the user. Alternatively or additionally, browser extension <NUM> may capture screenshots and other data associated with particular actions or types of actions by user <NUM>, which may significantly reduce the storage size of the browser session data. Accordingly, browser extension <NUM> may be configured to continuously monitor and detect various triggers based on activity of user <NUM>. For example, this may include clicking a mouse (e.g., left click, right click, or additional buttons), moving a mouse, hovering a mouse, touching a display screen, pressing a key on a keyboard, scrolling on a webpage, zooming in or out on a webpage, opening a new browser tab, closing a browser tab, switching to another browser tab, refreshing a webpage, navigating forward or back through the browser, resizing a browser window, navigating to another URL or web page, bookmarking a webpage, performing a copy or paste action, highlighting text or other elements of a webpage, or any other interactions by a user with a webpage, browser, or endpoint device. In some embodiments, data may be captured based on other triggers, such as at set time intervals, actions by user <NUM> on another device (e.g., a mobile phone, etc.), actions associated with other users in relation to user <NUM>, or other actions that may not be directly associated with interaction with user endpoint device <NUM>.

Based on a detected trigger, browser extension <NUM> may capture a screenshot <NUM>. Screenshot <NUM> may include a captured image representing contents of active window <NUM> as it is displayed to user <NUM>. For example, as shown in <FIG>, user <NUM> may click on an element <NUM> within protected navigation location <NUM> using cursor <NUM>. This clicking action may trigger browser extension <NUM> to capture a screenshot of the current display of active tab <NUM>. For example, this may include capturing a screenshot including element <NUM>, an image <NUM>, and any other elements displayed in browser <NUM>. Browser extension <NUM> may capture additional screenshots based on subsequent trigger actions by user <NUM>.

In some embodiments, browser extension <NUM> may further capture metadata <NUM> based on detected triggers. For example, metadata <NUM> may be captured along with each of screenshots <NUM>. Metadata <NUM> may include any additional data associated with protected navigation location <NUM>, browser <NUM>, user endpoint device <NUM>, or user <NUM> that may provide context for a screenshot. For example, this may include the type of activity that triggered the capture, a position of cursor <NUM> (e.g., in x-y coordinates), information regarding element <NUM> (e.g., a type of element, location, size, etc.), the URL or network address of active tab <NUM>, a webpage title, timestamp data, location data (e.g., based on global positioning system (GPS), internet protocol (IP) address data, etc.), a tenant identifier, an identifier of the current session, a user identifier, an application identifier, an IP address of user endpoint device <NUM>, a window height and width of browser <NUM>, browser information (e.g., browser type, version, etc.), information about user endpoint device <NUM> (e.g., model, serial number, operating system version, battery percentage, etc.), data displayed on protected navigation location <NUM> (e.g., keywords, text near cursor <NUM>, text obtained through optical character recognition of images, etc.), or a wide variety of other forms of data that may be relevant for auditing purposes.

As noted above, browser extension <NUM> may encrypt the recorded browser session data prior to transmitting it to server <NUM>. For example, browser extension <NUM> may be configured to encrypt screenshots <NUM> and metadata <NUM> using first auditor key <NUM>. Browser extension <NUM> may further encrypt session key <NUM> using first auditor key <NUM>. Browser extension <NUM> may then transmit the encrypted browser session data and the encrypted first auditor key to server <NUM>. Accordingly, server <NUM> may not have access to the unencrypted browser session data, or the auditor private key, in some embodiments.

<FIG> is a block diagram illustrating an example process <NUM> for recording browser session data at a user endpoint device, consistent with the disclosed embodiments. In particular, process <NUM> may represent a recording phase in which activity of user <NUM> associated with a protected navigation location is recorded. As used herein, a recording may not necessarily refer to a continuous recording of all activities of a user, but may refer to a collection of particular data associated with a sensitive session, additional details of which are provided below. Process <NUM> may further include various security steps to enable recorded browser session data to be securely transmitted to server <NUM> and stored on server <NUM> for future auditing purposes.

As an initial step, process <NUM> may include an authentication step <NUM>, in which user endpoint device <NUM> (or another device associated with user <NUM>) performs an authentication of user <NUM>. This authentication may be performed using a variety of suitable authentication methods. For example, in some embodiments, authentication <NUM> may include a password-based authentication through which user <NUM> provides a username, password, and/or other credentials for verification of an identity of user <NUM>. Various other authentication methods may be used, such as certificate-based authentication, biometric authentication, token-based authentication, or the like. In some embodiments, a multi-factor authentication may be performed, in which two or more independent ways to verify user <NUM> are used. For example, in some embodiments, the user may be directed for authentication to an IDP as a first authentication factor, and may be directed to a secured web page configured to act as a second authentication factor. In some embodiments, this second factor may include displaying an HTML element, such as HTML element <NUM>, within browser <NUM> on user endpoint device <NUM>. This HTML element may be used to further verify the identity of user <NUM>. In some embodiments, server <NUM> may be involved in authentication. For example, server <NUM> may be configured to validate one or more credentials of user <NUM>, or perform various other security functions.

In some embodiments, process <NUM> may include an initiation step <NUM> in which a browser session associated with user <NUM> is initiated and recorded. In some embodiments, the session may be initiated based on a navigation by user <NUM> to a protected navigation location. For example, user <NUM> may navigate to a protected navigation location <NUM> using browser <NUM>. In some embodiments initiation step <NUM> may include generating session key <NUM> and accessing first auditor key <NUM>, as described in further detail above with respect to <FIG>.

Process <NUM> may further include a recording step <NUM>. For example, this may include recording screenshots <NUM> and metadata <NUM>, as described above. In some embodiments, recording step <NUM> may include detecting one or more trigger actions by browser extension <NUM>. Based on the detected trigger actions, browser extension <NUM> may capture screenshots and associated metadata to be stored on server <NUM> for future auditing. In step <NUM>, browser extension <NUM> may perform an encryption step, as described above with respect to <FIG>. In particular, browser extension <NUM> may encrypt screenshots <NUM> and metadata <NUM> using session key <NUM> to produce encrypted browser session data <NUM>. Browser extension <NUM> may further encrypt session key <NUM> using first auditor key <NUM> to produce encrypted session key <NUM>. Browser extension <NUM> may then transmit the encrypted browser session data <NUM> and encrypted session key <NUM> to server <NUM> in step <NUM>. Server <NUM> may then store encrypted browser session data <NUM> and encrypted session key <NUM>, for example, in database <NUM>.

<FIG> is a block diagram illustrating an example process <NUM> for auditing browser session data at a user endpoint device, consistent with the disclosed embodiments. In particular, process <NUM> may represent an auditing phase in which browser session data recorded according to process <NUM> is reviewed by an auditor, such as auditor <NUM>.

In step <NUM>, auditor <NUM> may access a URL or other network location associated with auditing of recorded browser sessions. For example, in some embodiments, auditor <NUM> may navigate to a particular recording auditing location provided by server <NUM> (e.g., as a SaaS) for auditing recorded browser sessions. In some embodiments, step <NUM> may further include authenticating auditor <NUM>. For example, auditor <NUM> may be required to provide one or more credentials to validate the identity of auditor <NUM>. In step <NUM>, auditor endpoint device <NUM> may submit an audit request <NUM> to server <NUM>. In some embodiments, audit request <NUM> may be associated with a particular browser session. For example, auditor endpoint device <NUM> may request access to one or more of screenshots <NUM> and associated metadata <NUM>. Accordingly, server <NUM> may access encrypted browser session data <NUM> and encrypted session key <NUM>.

In step <NUM>, server <NUM> may retrieve encrypted browser session data <NUM> and encrypted session key <NUM> from storage based on audit request <NUM>. As described above with respect to step <NUM> (<FIG>), encrypted browser session data <NUM> and encrypted session key <NUM> may be stored in a storage location, such as database <NUM>. Accordingly, step <NUM> may include retrieving encrypted browser session data <NUM> and encrypted session key <NUM> from database <NUM> or any other storage location that may be used to store recorded browser session data.

In step <NUM>, server <NUM> may then transmit encrypted browser session data <NUM> and encrypted session key <NUM> to auditor endpoint device <NUM> in response to the audit request. In some embodiments, server <NUM> may be configured to provide selected subsets of the encrypted browser session data to auditor endpoint device <NUM>. For example, process <NUM> may include a step <NUM> in which server <NUM> receives a selection of a subset of the browser session data from auditor endpoint device <NUM>. In some embodiments, this may be based on interaction by auditor <NUM> with an interface <NUM> (described below with respect to <FIG>). The selected subset may be defined in various ways. For example, auditor <NUM> may select a particular trigger event, and based on the selection, screenshots and metadata associated with that event may be transmitted. As another example, auditor <NUM> may select a particular user, or a particular user session, and the encrypted browser session data associated with that selected user or user session may be transmitted to auditor endpoint device <NUM>. The selected subset may be defined in various other ways, such as a selection of a range of times, a range of events, selection of one or more events, a search function (e.g., for a particular event type, a particular URL, a particular keyword, etc.), a filter function (e.g., filtering by time range, event type, etc.), or any other ways to narrow or filter browser session data. Accordingly, in step <NUM>, server <NUM> may transmit a selected subset of encrypted browser session data <NUM> based on selection <NUM>.

In some embodiments, auditor endpoint device <NUM> may have access to a second auditor key <NUM>. For example, auditor endpoint device <NUM> may have received second auditor key <NUM> from key storage device <NUM> as described below in steps <NUM>-<NUM>. In some embodiments, second auditor key <NUM> may be a private auditor key of a tenant associated with user <NUM> and auditor <NUM>. Second auditor key <NUM> may be stored on key storage device <NUM> and used to decrypt the encrypted session key <NUM> in step <NUM> to produce session key <NUM>. Notably, second auditor key <NUM> may be stored such that it is inaccessible to server <NUM>.

In instances where auditor endpoint device <NUM> has access to second auditor key <NUM>, auditor endpoint <NUM> may then retrieve second auditor key <NUM> from storage (e.g., within metadata of a browser, as a cookie, on a local memory device, etc.). Accordingly, auditor endpoint device <NUM> may then proceed to in step <NUM> and decrypt encrypted session key <NUM> using second auditor key <NUM> to produce session key <NUM>, and decrypt encrypted browser session data <NUM> using session key <NUM> to access screenshots <NUM> and metadata <NUM>. Auditor endpoint device <NUM> may then allow a user <NUM> to audit the screenshots <NUM> and metadata <NUM> in step <NUM>, for example through an interface <NUM> described in further detail below.

In some embodiments, auditor endpoint device <NUM> may not have access to second auditor key <NUM>. For example, auditor endpoint device <NUM> may be configured to store auditor keys temporarily (e.g., in a transient memory), may not have received second auditor key <NUM> previously, may have an expired second auditor key <NUM>, or the like. Accordingly, auditor endpoint device <NUM> may execute steps for receiving second auditor key <NUM> from key storage device <NUM>. In some embodiments, this may include a step <NUM> in which auditor endpoint device <NUM> generates one or more transmission keys <NUM> and <NUM>. Transmission keys <NUM> and <NUM> may be used to provide additional security for communications between auditor endpoint device <NUM>, key storage device <NUM>, and server <NUM> associated with second auditor key <NUM>. It is to be understood, however, that in some embodiments, a similar process may be performed without transmission keys <NUM> and <NUM>. In some embodiments, transmission keys <NUM> and <NUM> may be a private/public key pair. For example, a first transmission key <NUM> may be a public transmission key and a second transmission key <NUM> may be a private key. Alternatively or additionally, transmission keys <NUM> and <NUM> may be a symmetric key pair. In some embodiments, auditor endpoint device <NUM> may also generate a transmission identifier <NUM>, which may be associated with transmission keys <NUM> and <NUM>.

In step <NUM>, auditor endpoint device <NUM> may transmit (or otherwise make available) first transmission key <NUM> and transmission ID <NUM> to key storage device <NUM>. In some embodiments, this may include encoding first transmission key <NUM> and transmission ID <NUM> in a machine-readable code, such as a barcode, quick response (QR) code, or other form of visual code. In some embodiments, this may include displaying the machine-readable code on a browser window so that it may be scanned by key storage device.

<FIG> illustrates an example interface for transferring data between auditor endpoint device <NUM> and key storage device <NUM>, consistent with the disclosed embodiments. As shown, a browser application <NUM> may be used to display a machine-readable code <NUM>. As with browser <NUM>, browser <NUM> may be any application configured to access webpages or other network locations through a network, such as the Internet. For example, browser <NUM> may be a web browser application, such as Google Chrome™, Mozilla Firefox™, Microsoft Edge™, Internet Explorer™, Safari™, or similar applications. Auditor <NUM> may navigate to a recording auditing navigation location <NUM>, which may provide access to recorded browser session data, as described above. In some embodiments, by navigating to recording auditing navigation location <NUM>, auditor endpoint device <NUM> may initiate audit request <NUM>.

As described above, auditor endpoint device <NUM> may generate a first transmission key <NUM> and transmission ID <NUM>. Auditor endpoint device <NUM> may then encode first transmission key <NUM> and transmission ID <NUM> in the form of machine-readable code <NUM>. In this example, machine-readable code <NUM> is represented as a QR code, however, it is to be understood that various other forms of machine-readable codes may be used. Auditor <NUM> may then scan machine-readable code <NUM> using key storage device <NUM>, as shown in <FIG>. Key storage device <NUM> may be configured to decode machine-readable code <NUM> to access first transmission key <NUM> and transmission ID <NUM>. Key storage device <NUM> may store a second auditor key <NUM>, which may be a private auditor key of an auditor key pair. First transmission key <NUM> may be used by key storage device <NUM> to encrypt second auditor key <NUM>. While <FIG> illustrates the use of machine-readable code <NUM> to provide first transmission key <NUM> and transmission ID <NUM> to key storage device <NUM>, it is to be understood that this is provided by way of example, and various other methods may be used to transmit first transmission key <NUM> and transmission ID <NUM> to key storage device <NUM>. For example, this may include another form of short-range communication, such as Bluetooth™, infrared, near-field communication (NFC) or various other types of short-range communication methods or protocols.

Returning to <FIG>, in step <NUM>, key storage device <NUM> may then encrypt second auditor key <NUM> using first transmission key <NUM> (received in step <NUM>) to produce encrypted second auditor key <NUM>. This may ensure that second auditor key <NUM> is not transmitted unencrypted from mobile device <NUM> to server <NUM>. In some embodiments, process <NUM> may further include a step <NUM> of authenticating auditor <NUM> at key storage device <NUM>. For example, this may include a biometric authentication (e.g., based on a fingerprint, palm print, vein pattern, facial recognition, DNA, hand geometry, iris or retina identification, gait or other behavioral characteristics, or the like), or any other form of authentication. This authentication may enable access to second auditor key <NUM> through key storage device <NUM>. In step <NUM>, key storage device <NUM> may transmit encrypted second auditor key <NUM> along with transmission ID <NUM> to server <NUM>. Server <NUM> may then store encrypted second auditor key <NUM> in step <NUM>.

In step <NUM>, auditor endpoint device <NUM> may retrieve encrypted second auditor key <NUM> from server <NUM>. In some embodiments, encrypted second auditor key <NUM> may be stored in a known or specified location on server <NUM>. In some embodiments, the location may be specified based on transmission ID <NUM>. For example, auditor endpoint device <NUM> may reference transmission ID <NUM> (generated in step <NUM>) to locate the encrypted second auditor key <NUM>. As part of step <NUM>, auditor endpoint device <NUM> may then decrypt encrypted second auditor key <NUM> using second transmission key <NUM> to produce second auditor key <NUM>. Accordingly, as a result of steps <NUM>-<NUM>, auditor endpoint device <NUM> may access second auditor key <NUM> in a secure manner.

In the example described above with respect to steps <NUM>-<NUM>, key storage device may be an auditor mobile device configured to provide second auditor key <NUM> based on authentication of auditor <NUM>. While steps <NUM>-<NUM> are provided by way of example, various other steps for retrieving second auditor key <NUM> may be used, which may depend on a type of key storage device that is used. Accordingly, steps <NUM>-<NUM> may not necessarily be applicable for other forms of key storage devices. For example, key storage device <NUM> may be a flash drive or other memory device configured to store second auditor key <NUM> and provide second auditor key <NUM> through a communication link, such as a USB interface, Bluetooth™, NFC, or any other forms of short-range communication. In some embodiments, this may include an authentication step for authenticating auditor <NUM>. For example, key storage device <NUM> may further include a fingerprint scanner or other biometric device for authenticating auditor <NUM> and may transfer second auditor key <NUM> to auditor endpoint device <NUM> based on a successful authentication. Alternatively or additionally, the authentication may occur through auditor endpoint device <NUM>. For example, auditor <NUM> may provide credentials, biometric information, other any other form of authentication information through auditor endpoint device <NUM>. As another example, key storage device <NUM> may be integrated with auditor endpoint device <NUM> (e.g., as part of memory <NUM>). Accordingly, second auditor key <NUM> may be stored within auditor endpoint device <NUM> in a secure location and key storage device <NUM> may take the form of a software-based authenticator configured to allow second auditor key <NUM> to be retrieved based on an authentication of auditor <NUM> at auditor endpoint device <NUM>. In some embodiments, a WebAuthn standard or other form of web-based authentication standard may be used for securely storing second auditor key <NUM>. While various examples are provided herein, it is to be understood that the present disclosure is not limited to any particular form of key storage device or methods for securely providing second auditor key <NUM> to auditor endpoint device <NUM>.

Notably, regardless of the type of key storage device <NUM> that is used, server <NUM> may not have access to second auditor key <NUM> in an unencrypted form and therefore may not have access to session key <NUM> or the recorded browser session data. In some embodiments, auditor endpoint device <NUM> may then store second auditor key <NUM> for future access.

As described above, step <NUM> may include decrypting encrypted session key <NUM> using second auditor key <NUM> to produce session key <NUM>. Further, step <NUM> may include decrypting encrypted browser session data <NUM> using session key <NUM> to provide access to screenshots <NUM> and metadata <NUM>. Process <NUM> may then include a step <NUM> in which a user (e.g., auditor <NUM>) may review screenshots <NUM> and metadata <NUM>. In some embodiments, this may be performed through an interface <NUM>, as described further below.

As a result of process <NUM>, screenshots <NUM> and metadata <NUM> may be transmitted from server <NUM> to auditor endpoint device <NUM> in a secure manner. In particular, server <NUM> may not have access to screenshots <NUM> and metadata <NUM> in an unencrypted form. Server <NUM> further may not have access to second auditor key <NUM> in an unencrypted form, which may be required to access screenshots <NUM> and metadata <NUM>. Moreover, in some embodiments, only particular data associated with a recorded browser session may be transmitted (e.g., based on selection <NUM>), which may further improve security and reduce storage, transmission, and processing bandwidth requirements.

<FIG> illustrates an example interface <NUM> for auditing recorded browser session data, consistent with the disclosed embodiments. Interface <NUM> may be displayed on an auditor endpoint device for reviewing browser session data. For example, interface <NUM> may be displayed through auditor endpoint device <NUM> as part of step <NUM> described above to allow auditor <NUM> to review and navigate screenshots <NUM> and/or metadata <NUM>. Interface <NUM> may include a navigation pane <NUM> and a display pane <NUM>. Auditor <NUM> may interact with navigation pane to navigate and/or select various screenshots or metadata. Selected information may then be displayed in display pane <NUM>.

In some embodiments, navigation pane <NUM> may include a timeline <NUM> through which various events may be presented chronologically. For example, as shown in <FIG>, timeline <NUM> may include events <NUM> and <NUM>. The events in timeline <NUM> may correspond to trigger events that caused screenshots and other metadata to be displayed. Accordingly, selection of one or more of the events in timeline <NUM> may cause the corresponding data associated with the event to be displayed in display pane <NUM>. Timeline may further include other information associated with an event, such as a timestamp, an event type, a URL or network location, a page title, an indication of which tab is active, a number of times a user has visited a page, or any other information that may be associated with an event. Timeline <NUM> may be populated based on information stored in metadata <NUM>.

As an illustrative example, auditor <NUM> may select event <NUM>, which may correspond to user <NUM> clicking a mouse of user endpoint device <NUM>. For example, this may include clicking element <NUM>, as described above with respect to <FIG>. In some embodiments, a visual indicator <NUM> may indicate which event has been selected and is being displayed in display pane <NUM>. In this example, visual indicator <NUM> may be a highlight of event <NUM> in a different shade or color. Various other visual indicators may be used, such as display of a graphical icon, a change in font of event <NUM> (e.g., bold, italics, changes in color, etc.), an outline, or any other change to visibly distinguish a selected element.

Based on the selection of event <NUM>, interface <NUM> may display screenshot <NUM>, which may have been captured based on user <NUM> clicking on element <NUM>. In some embodiments, display pane <NUM> may include other elements based on metadata associated with screenshot <NUM>. For example, this may include overlaying a marker <NUM>, which may indicate a location of cursor <NUM> when user <NUM> clicked on element <NUM>. As another example, display pane <NUM> may include a marker <NUM> highlighting or otherwise indicating which element user <NUM> interacted with. Display pane <NUM> may include other information from metadata <NUM>, including URL <NUM> (which may correspond to protected navigation location <NUM>), a page title, a window height and width, text (e.g., processed through OCR, etc.), or various other forms of information, including any of the various forms of metadata described above.

Timeline <NUM> may further include an event <NUM> associated with user <NUM> switching tabs in browser <NUM>. Selecting event <NUM> may update the screenshot and other information displayed in display pane <NUM>. For example, selecting <NUM> may cause a screenshot of a tab that user <NUM> switched to (e.g., tab <NUM>) to be displayed in display pane <NUM>. In some embodiments, display pane <NUM> may display information for more than one event overlaid on the same screenshot. For example, if user <NUM> also clicked image <NUM> within URL <NUM>, additional markers may be displayed on the same screenshot <NUM>. In some embodiments, display pane <NUM> may be interactive. For example, auditor <NUM> may click on marker <NUM> (or marker <NUM>), which may cause display pane <NUM> to be updated to display a screenshot of what user <NUM> was presented upon clicking element <NUM>.

In some embodiments, interface <NUM> may include additional elements for searching or filtering browser session data associated with a user or tenant. For example, interface <NUM> may include a search bar <NUM> through which auditor <NUM> may search for particular keywords, or other metadata information included in metadata <NUM>. Additionally or alternatively, interface <NUM> may include a filter element <NUM> through which auditor <NUM> may filter data to be displayed in navigation pane <NUM>. For example, this may include filtering particular users, particular time or date ranges, particular URLs or domains, or various other filters that may be applied to metadata <NUM>. In some embodiments, interface <NUM> may display other information, such as information about user <NUM>, a date of a recording, a length or time of a recording, credentials or privileges of user <NUM>, or any other information associated with one or more recorded browser sessions.

<FIG> is a flowchart showing an example process <NUM> for securely and privately auditing web sessions, consistent with the disclosed embodiments. Process <NUM> may be performed by at least one processing device of a server, such as processor <NUM>, as described above. In some embodiments, a non-transitory computer readable medium may contain instructions that when executed by a processor cause the processor to perform process <NUM>. Further, process <NUM> is not necessarily limited to the steps shown in <FIG>, and any steps or processes of the various embodiments described throughout the present disclosure may also be included in process <NUM>, including those described above with respect to, for example, <FIG> and <FIG>.

In step <NUM>, process <NUM> may include receiving, from a browser extension executing on a user endpoint device, encrypted browser session data and an encrypted session key. For example, this may include receiving encrypted browser session data from browser extension <NUM>. The encrypted browser session data may comprise browser session data recorded by the browser extension and encrypted by the browser extension using a session key. For example, the browser session data may include screenshots <NUM> and metadata <NUM>, which may be encrypted using session key <NUM>. In some embodiments, the browser session data may be derived from actions taken by a user during a browser session. For example, user <NUM> may interact with a protected navigation location <NUM>, which may include clicking on one or more elements, navigating a webpage, interacting with browser tabs, or the like. As described above, the browser may be configured to detect various recording triggers and capture screenshots and other metadata by the triggers. Accordingly, the browser session may detect a recording trigger associated with the endpoint device and record the browser session data based on the detected recording trigger. In some embodiments, this recording trigger may be invoked in response to an action taken by a user during the browser session.

The encrypted session key may comprise the session key having been encrypted by the browser extension using a first auditor key. In some embodiments, the browser extension may be configured to generate the session key. For example, the browser extension may be configured to detect that a user has navigated to a protected navigation location and may generate the session key based on the detected navigation to the protected navigation location.

In some embodiments, the first auditor key may be associated with a tenant. For example, as described above, a tenant may be an organization or other entity or group of entities associated with user <NUM>. As described above, step <NUM> may further include making the first auditor key available to the browser extension. For example, this may include embedding the first auditor key in an HTML element displayed through the browser, providing the first auditor key through a cookie or token, or various other methods. The first auditor key may be made available to the browser extension based on an indication of the tenant. For example, user <NUM> may provide authentication credentials, which may indicate the tenant, and the first auditor key may be provided based on identification of the tenant.

In step <NUM>, process <NUM> may include storing the encrypted browser session data and the encrypted session key. For example, this may include storing encrypted browser session data <NUM> and encrypted session key <NUM> in database <NUM>, as described above with respect to step <NUM>.

In step <NUM>, process <NUM> may include receiving, from an auditor endpoint device, an audit request associated with the stored encrypted browser session data. For example, this may include receiving an audit request from auditor endpoint device <NUM>, as described above with respect to step <NUM>. In some embodiments, the audit request may be based on an auditor identity navigating to a recording auditing navigation location. For example, a recording auditing navigation location may be defined such that when auditor <NUM> navigates to the recording auditing navigation location, an audit session request is initiated. In some embodiments, the particular recording auditing navigation location may be unique to a tenant associated with auditor <NUM>.

In step <NUM>, process <NUM> may include retrieving the stored encrypted browser session data and the stored encrypted session key based on the audit request. For example, step <NUM> may correspond to step <NUM> described above. In some embodiments, step <NUM> may include retrieving a subset of encrypted browser session data <NUM>. For example, process <NUM> may further include receiving, from the auditor endpoint device, an indication of a selected subset of the encrypted browser session data, as described above with respect to step <NUM>. This subset may be defined in various ways. For example, the selected subset may be selected based on one or more of a particular trigger event, a particular user, a particular user session, a range of times, a range of events, a selection of one or more events, a search function, and a filter function.

In step <NUM>, process <NUM> may include transmitting at least some of the encrypted browser session data and the encrypted session key to the auditor endpoint device. For example, step <NUM> may correspond to step <NUM>, as described above. In some embodiments, transmitting at least some of the encrypted browser session data to the auditor endpoint device may comprise transmitting a selected subset of the encrypted browser session data, as described above. Step <NUM> may enable access to the browser session data by the auditor endpoint device. For example, the auditor endpoint device may be configured to access a second auditor key associated with the tenant from a key storage device. In some embodiments, the key storage device may be a mobile device, as described above. The auditor endpoint device may further be configured to decrypt the encrypted session key using the second auditor key and decrypt the encrypted browser session data using the decrypted session key to enable access to the browser session data.

In some embodiments, accessing the second auditor key may include accessing the second auditor key from a storage location associated with the browser or browser extension. Alternatively or additionally, accessing the second auditor key may include prompting the key storage device to provide the second auditor key, which may include additional encryption of the second auditor key. For example, this may include generating a transmission key pair comprising a first transmission key and a second transmission key; transmitting the first transmission key to a key storage device, wherein the key storage device is configured to: retrieve an encrypted second auditor key from a storage location, the encrypted second auditor key having been encrypted by the key storage device using the first transmission key and transmit the encrypted second auditor key to a specified network location; retrieving the encrypted second auditor key from the specified network location; and decrypting the encrypted second auditor key using the second transmission key. In some embodiments, accessing the second auditor key from the key storage device may further comprise generating a transmission identifier; transmitting the transmission identifier to the auditor endpoint device; and selecting the second transmission key based on the transmission identifier. In some embodiments, the auditor endpoint device may be configured to present the first transmission key to the key storage device via a short-range communication. For example, the short-range communication may include at least one of displaying a machine-readable code encrypting the transmission key or transmitting the transmission key via a short-range communication protocol. In some embodiments, the key storage device is configured to encrypt the second auditor key based on an authentication of an auditor identity using the key storage device.

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

The disclosed embodiments may be implemented in a system, a method, and/or a computer program product.

The flowcharts and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a software program, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

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

Claim 1:
A computer-implemented method for securely and privately auditing secured web sessions, the method comprising:
receiving, at a server from a user endpoint device, encrypted browser session data, wherein the encrypted browser session data comprises browser session data recorded by a browser extension and encrypted by the browser extension using a first auditor key associated with an organization of a user, the browser extension executing on the user endpoint device;
storing the encrypted browser session data at the server;
receiving, at the server from an auditor endpoint device, an audit request associated with the stored encrypted browser session data;
retrieving, by the server, the stored encrypted browser session data based on the audit request;
transmitting at least some of the encrypted browser session data from the server to the auditor endpoint device to enable access to the browser session data by the auditor endpoint device, wherein the auditor endpoint device is configured to:
access a second auditor key associated with the organization from a key storage device; and
decrypt the encrypted browser session data using the second auditor key to enable access to the browser session data.