DATA CLUTCH FOR UNMATCHED NETWORK RESOURCES

A method includes at a first electronic device, receiving at a browser, a first request for data, wherein the first request includes a first identifier of a location of the data on a network, passing the first request from the browser to a gateway, performing, by the gateway, a comparison of the first identifier against items of a first list and items of a second list. When the identifier is not an item of the first list or an item of the second list, initiating, by the gateway, a data clutch including sending from the gateway to a trusted device, a request for manual authorization to be displayed by the browser, receiving, from the trusted device, manual authorization, passing, an approval request to an authorization layer, and receiving, by the browser, an approval from the authorization layer in response to the approval request, and obtaining the requested data.

TECHNICAL FIELD

This disclosure relates generally to network security and mitigating the risk of malicious interaction between machines of a secure network and unknown actors on an outside network. More specifically, the present disclosure is directed to systems and methods for implementing a data clutch for actuating interactions between machines of a secure network and unfamiliar resources of an outside network.

BACKGROUND

The risks associated with receiving data and communications from unvetted or unfamiliar resources of an outside network (for example, the internet) include, without limitation, insertion of malware onto an internal network, phishing attacks, and parasitic overconsumption of network resources through unwanted network traffic with a malicious actor on an outside network (for example, DDOS attacks) are well known and present a serious and persistent technical challenge in the field of network security.

Historically, hardening internal networks against the well-recognized threats from actors associated with unfamiliar web addresses has required compromises across one or more dimensions of network or device performance. As one example, filtering and web security applications can be installed on the individual machines of the network. However, the security gains of this approach typically come at the cost of performance on the individual machines (which are running an additional application), and increased administrative challenges associated with ensuring that updates to the security application are pushed out to individual machine of the network. Another approach is to implement and maintain lists of allowed and/or blocked network locations (previously referred to as “whitelists” and “blacklists”). While this approach can effect some security gains, these gains likewise come, at a minimum, at the administrative costs of having to diligently and continuously updated the gating lists to keep pace with the discovery of network locations of interest. Further, this approach also leaves open the issue of what to do with network addresses that have neither been confirmed as safe (i.e., members of an “allowed list”) nor confirmed as malicious (i.e., as members of a “blocked list.”).

Accordingly, hardening internal networks against the risks associated with interactions with unmatched (i.e., not having been matched to an “allowed” or “blocked” category) network resources without imposing unwanted performance costs, such as in terms of processing overhead, or increased management burden for network administrators, presents a source of technical challenges and opportunities for improvements in the art.

SUMMARY

This disclosure provides to systems and methods for implementing a data clutch for actuating interactions between machines of a secure network and unfamiliar resources of an outside network.

In a first embodiment, a method includes, at a first electronic device having a processor and connected to a network, receiving at a browser, a first request for access to a network resource, wherein the first request includes a first identifier of a location on the network. The method further includes passing the first request from the browser to a gateway, performing, by the gateway, a comparison of the first identifier against items of a first list and items of a second list, responsive to determining, based on the comparison, that the first identifier is not an item of the first list or an item of the second list, initiating, by the gateway, a data clutch process. The data clutch process includes sending from the gateway to a trusted device, a request for manual authorization, receiving manual authorization at the trusted device, responsive to notification of the manual authorization, passing an approval request to an authorization layer, and receiving, by the browser, an approval from the authorization layer in response to the approval request. The method further includes responsive to receiving the approval from the authorization layer, accessing the requested network resource.

In a second embodiment, an apparatus includes a network interface connected to a network, a processor and a memory containing instructions. When the instructions are executed by the processor, they cause the apparatus to receive at a browser executing on the apparatus, a first request for access to a network resource, wherein the first request includes a first identifier of a location on the network, pass the first request from the browser to a gateway for comparison of the first identifier against items of a first list and items of a second list, responsive to a determination by the gateway that the identifier is not an item of the first list or an item of the second list, receive, from the gateway, a request for manual authorization to be displayed by the browser, obtain notification of manual authorization at a trusted device, responsive to receiving notification of the manual authorization, pass an approval request to an authorization layer, receive, by the browser, an approval from the authorization layer in response to the approval request, and responsive to receiving the approval from the authorization layer, access the requested network resource.

In a third embodiment, a non-transitory computer program product includes program code, which, when executed by a processor, causes an apparatus to receive at a browser executing on the apparatus, a first request for access to a network resource, wherein the first request includes a first identifier of a location on the network, pass the first request from the browser to a gateway for comparison of the first identifier against items of a first list and items of a second list, responsive to a determination by the gateway that the identifier is not an item of the first list or an item of the second list, receive, from the gateway, a request for manual authorization to be displayed by the browser, obtain notification of manual authorization at a trusted device, responsive to receiving notification of the manual authorization, pass an approval request to an authorization layer, receive, by the browser, an approval from the authorization layer in response to the approval request, and responsive to receiving the approval from the authorization layer, access the requested network resource.

DETAILED DESCRIPTION

FIG.1illustrates a non-limiting example of a device100for accessing unfamiliar resources of an outside network according to some embodiments of this disclosure. According to various embodiments of this disclosure, device100could be implemented as one or more of a smartphone, a tablet, or a laptop computer. The embodiment of device100illustrated inFIG.1is for illustration only, and other configurations are possible. However, suitable devices come in a wide variety of configurations, andFIG.1does not limit the scope of this disclosure to any particular implementation of a device.

As shown in the non-limiting example ofFIG.1, the device100includes a communication unit110that may include, for example, a radio frequency (RF) transceiver, a BLUETOOTH transceiver, or a WI-FI transceiver, etc., transmit (TX) processing circuitry115, a microphone120, and receive (RX) processing circuitry125. The device100also includes a speaker130, a main processor140, an input/output (I/O) interface (IF)145, input/output device(s)150, and a memory160. The memory160includes an operating system (OS) program161and one or more applications162.

Applications162can include web browsers, games, social media applications, applications for geotagging photographs and other items of digital content, virtual reality (VR) applications, augmented reality (AR) applications, operating systems, device security (e.g., anti-theft and device tracking) applications or any other applications which access resources of device100and can attempt to connect with machines on an outside network. According to some embodiments, the resources of device100include, without limitation, speaker130, microphone120, input/output devices150, and additional resources180.

The communication unit110may receive an incoming RF signal, for example, a near field communication signal such as a BLUETOOTH or WI-FI signal. The communication unit110can down-convert the incoming RF signal to generate an intermediate frequency (IF) or baseband signal. The IF or baseband signal is sent to the RX processing circuitry125, which generates a processed baseband signal by filtering, decoding, or digitizing the baseband or IF signal. The RX processing circuitry125transmits the processed baseband signal to the speaker130(such as for voice data) or to the main processor140for further processing (such as for web browsing data, online gameplay data, notification data, or other message data). Additionally, communication unit110may contain a network interface, such as a network card, or a network interface implemented through software.

The TX processing circuitry115receives analog or digital voice data from the microphone120or other outgoing baseband data (such as web data, e-mail, or interactive video game data) from the main processor140. The TX processing circuitry115encodes, multiplexes, or digitizes the outgoing baseband data to generate a processed baseband or IF signal. The communication unit110receives the outgoing processed baseband or IF signal from the TX processing circuitry115and up-converts the baseband or IF signal to an RF signal for transmission.

The main processor140can include one or more processors or other processing devices and execute the OS program161stored in the memory160in order to control the overall operation of the device100. For example, the main processor140could control the reception of forward channel signals and the transmission of reverse channel signals by the communication unit110, the RX processing circuitry125, and the TX processing circuitry115in accordance with well-known principles. In some embodiments, the main processor140includes at least one microprocessor or microcontroller. According to certain embodiments, main processor140is a low-power processor, such as a processor which includes control logic for minimizing consumption of battery199or minimizing heat buildup in device100.

The main processor140is also capable of executing other processes and programs resident in the memory160. The main processor140can move data into or out of the memory160as required by an executing process. In some embodiments, the main processor140is configured to execute the applications162based on the OS program161or in response to inputs from a user or applications162. Applications162can include applications specifically developed for the platform of device100, or legacy applications developed for earlier platforms. The main processor140is also coupled to the I/O interface145, which provides the device100with the ability to connect to other devices such as laptop computers and handheld computers. The I/O interface145is the communication path between these accessories and the main processor140.

The main processor140is also coupled to the input/output device(s)150. The operator of the device100can use the input/output device(s)150to enter data into the device100. Input/output device(s)150can include keyboards, touch screens, mouse(s), track balls or other devices capable of acting as a user interface to allow a user to interact with device100. In some embodiments, input/output device(s)150can include a touch panel, an augmented or virtual reality headset, a (digital) pen sensor, a key, or an ultrasonic input device.

Input/output device(s)150can include one or more screens, which can be a liquid crystal display, light-emitting diode (LED) display, an optical LED (OLED), an active matrix OLED (AMOLED), or other screens capable of rendering graphics.

The memory160is coupled to the main processor140. According to certain embodiments, part of the memory160includes a random access memory (RAM), and another part of the memory160includes a Flash memory or other read-only memory (ROM). AlthoughFIG.1illustrates one example of a device100. Various changes can be made toFIG.1.

For example, according to certain embodiments, device100can further include a separate graphics processing unit (GPU)170.

According to certain embodiments, device100includes a variety of additional resources180which can, if permitted, be accessed by applications162. According to certain embodiments, additional resources180include an accelerometer or inertial measurement unit (IMU)182, which can detect movements of the electronic device along one or more degrees of freedom. Additional resources180include, in some embodiments, one or more dynamic vision sensors184, and one or more cameras186(for example, complementary metal oxide semiconductor (CMOS) sensor type cameras) of device100. According to various embodiments, DVS sensor(s)184comprises a pair of dynamic vision sensors spaced at a stereoscopically appropriate distance for estimating depth at over a field of depth of interest. According to some embodiments DVS sensor(s)184comprise a plurality of DVS sensors with overlapping, or partially overlapping fields of view.

According to various embodiments, the above-described components of device100are powered by battery199(for example, a rechargeable lithium-ion battery), whose size, charge capacity and load capacity are, in some embodiments, constrained by the form factor and user demands of the device. As a non-limiting example, in embodiments where device100is a smartphone, battery199is configured to fit within the housing of the smartphone and is configured not to support current loads (for example, by running a graphics processing unit at full power for sustained periods) causing heat buildup.

AlthoughFIG.1illustrates one example of a device100for accessing unfamiliar resources of an outside network, various changes may be made toFIG.1. For example, the device100could include any number of components in any suitable arrangement. In general, devices including computing and communication systems come in a wide variety of configurations, andFIG.1does not limit the scope of this disclosure to any particular configuration. WhileFIG.1illustrates one operating environment in which various features disclosed in this patent document can be used, these features could be used in any other suitable system.

FIG.2illustrates an example of a server200that can be configured to act as a secure web gateway or secure access server according to certain embodiments of this disclosure. The embodiment of the server200shown inFIG.2is for illustration only and other embodiments could be used without departing from the scope of the present disclosure. According to certain embodiments, server200operates as a gateway for data passing between a device of a secure internal network (for example, device100inFIG.1), and an unregulated external network, such as the internet.

In the example shown inFIG.2, the server200includes a bus system205, which supports communication between at least one processing device210, at least one storage device215, at least one communications unit220, and at least one input/output (I/O) unit225.

The processing device210executes instructions that may be loaded into a memory230. The processing device210may include any suitable number(s) and type(s) of processors or other devices in any suitable arrangement. Example types of processing devices210include microprocessors, microcontrollers, digital signal processors, field programmable gate arrays, application specific integrated circuits, and discrete circuitry.

The memory230and a persistent storage235are examples of storage devices215, which represent any structure(s) capable of storing and facilitating retrieval of information (such as data, program code, and/or other suitable information on a temporary or permanent basis). The memory230may represent a random-access memory or any other suitable volatile or non-volatile storage device(s). The persistent storage235may contain one or more components or devices supporting longer-term storage of data, such as a ready only memory, hard drive, Flash memory, or optical disc.

The communications unit220supports communications with other systems or devices. For example, the communications unit220could include a network interface card or a wireless transceiver facilitating communications over the network102. The communications unit220may support communications through any suitable physical or wireless communication link(s).

The I/O unit225allows for input and output of data. For example, the I/O unit225may provide a connection for user input through a keyboard, mouse, keypad, touchscreen, or other suitable input device. The I/O unit225may also send output to a display, printer, or other suitable output device.

FIG.3Aillustrates an example of implementing a data clutch to actuate access to resources of an unmatched network location by a machine on a secure network, according to various embodiments of this disclosure.

Referring to the non-limiting example ofFIG.3A, the following four network actors are shown in this example—a browser301, a secure web gateway303, an authentication layer providing an application programming interface (API)305, and an unregulated network307(for example, the internet). In this illustrative example, a user309is also shown as an actor in this sequence of operations.

According to various embodiments, browser301comprises an application running on a computing platform (for example, device100inFIG.1) having access to, an internal network (for example, a company network), which is configured to access locations on one or more unregulated networks, including, without limitation, the World Wide Web. In this example, browser301receives as inputs, locations (for example, as specified by uniform resource locators (“URLs”) or internet protocol (IP) addresses) of resources (for example, web pages, or files for download) on one or more internal networks or on unregulated network307.

In certain embodiments, secure web gateway303is communicatively connected to browser301and implements a gatekeeping functionality for data passing to and from browser301and unregulated network307. In some embodiments, gateway303is embodied as an application executing on the same device as browser301. In other embodiments, such as, for example, enterprise-scale networks, gateway303is embodied as an application or suite of applications executing on one or more gateway servers (for example, server200inFIG.2). In some embodiments, gateway303is embodied as one or more applications executing on a cloud server. Further, in some embodiments, gateway303may be embodied on a cloud, or physical computing platform providing another network security functionality (for example, a virtual private network (VPN) server.

Referring to the non-limiting example ofFIG.3A, API305comprises an application processing interface communicatively connected to both browser301and gateway303, through which both browser301and gateway303can interface with back-end processes of the data clutch process, as described herein. According to some embodiments, API305is embodied through one or more applications executing on the same device as browser301. In certain embodiments, API305is embodied through one or more applications executing on a server (for example, server200inFIG.2) which is a separate computing platform from the device providing browser301. In certain embodiments, API305is embodied through one or more cloud-based applications. For example, in some embodiments, API305may be embodied at a cloud server or other networked computing platform providing another layer of network security, such as a VPN server.

Unregulated network307comprises a network of communicatively connected machines hosting resources which can be located by browser301, at least certain of which are neither known to either gateway303or API305and operate outside of the control of a network administrator having access to gateway303, API305and the device providing browser301. The Internet, or World Wide Web is one non-limiting example of an unregulated network according to various embodiments of this disclosure. In the non-limiting example ofFIG.3A, a human user309is shown as viewing content through browser301. Embodiments according to this disclosure are not so limited, and other architectures, in which a human or human-controlled process actuating a data clutch, may interact with a different application, which in turn, interacts with a browser, or otherwise presents requests for unmatched resources of an unregulated network.

Referring to the non-limiting example ofFIG.3A, at operation311, a user requests a network resource, in this example, “Webpage A” associated with a particular URL through browser301. In this example, the requested network resource is maintained on an unregulated network307on one or more machines outside of the control of an entity administering the machines providing browser301, gateway303, and API305. According to various embodiments, at operation313, the browser passes the request for the resource to gateway303. At operation315, the gateway performs a first comparison of an identifier of the requested network resource (for example, the domain name, URL or IP address) against a first list, wherein the first list comprises a list of identifiers of previously approved network resources (for example, approved web search pages, a company home page, etc.). According to various embodiments, at operation315, the gateway performs a second comparison of the identifier of the requested network resource against a list of identifiers of previously prohibited network resources (for example, websites associated with malicious code or office-inappropriate content). According to certain embodiments, the gateway may also perform a third comparison of the identifier to the requested network against a third list, comprising identifiers of previously requested unmatched network resources. Responsive to the identifier being matched to an element of the first list (i.e., gateway303can confirm that the requested resource has been previously adjudged to be acceptable), gateway303passes the request to unregulated network307. Similarly, responsive to the identifier being matched to an element of the second list (i.e., gateway303can confirm that the requested resource is unacceptable for viewing on devices of an administered network), gateway303blocks the request, and in some embodiments, returns a message to browser301that the request has been blocked.

However, skilled artisans will appreciate that the universe of bad actors and devices hosting harmful resources on unregulated, publicly accessible networks is a protean and, elusive target, with malicious actors readily being able to move harmful resources (for example, websites containing malware or other content which network administrators may wish to exclude) to locations associated with new identifiers. Thus, even with diligent updating and research, the contents of a “blocked” and “allowed” lists provide an imperfect and often out-of-date snapshot of the threat picture to a protected network, as many harmful network resources are unmatched resources. As used in this disclosure, the expression “unmatched resource” encompasses a resource of a network, for example, an unregulated network, such as unregulated network307, having an identifier which does not yet match any items on lists of allowed, blocked, or otherwise categorized lists of network resources maintained by a security system (for example, gateway303and API305) of an internal network.

Providing access to unmatched network resources presents a two-sided challenge with respect to balancing network administration issues and network security issues. On the one hand, for many enterprises, there is a significant cohort of users for whom it is unreasonable to limit their network access to just those network locations with identifiers on an allowed list. For many enterprises, the nature of their operations requires that at least some personnel (for example, journalists, certain law enforcement officers or other roles requiring research of other individuals' internet presence) be provided with broad access to unregulated networks, such as the internet. Thus, in many cases, it is not feasible for network administrators to limit access to unregulated networks to resources on an allowed list. At the same time, the universe of potential threats to an internal network can be large and rapidly evolving, meaning that a network security system focused only on excluding network resources matching to a blocked list is likely underinclusive and does to manage potential threat arising from unmatched network resources.

Certain embodiments according to the present disclosure provide a mechanism for managing access to unmatched resources in a way that balances providing a workable level of access for organizations that cannot limit their personnel's access to just an allowed list, while at the same time, provides heightened security over methods which only exclude resources matching a blocked list. Further, certain embodiments according to the present disclosure provide a mechanism for managing unmatched network resources which does not increase processing overhead at accessing devices (for example, the device providing browser301), and at the same time, without imposing any new need upon network administrators to keep and update lists of categorized network resources.

Referring to the non-limiting example ofFIG.3A, where, at operation315, gateway303determines that the requested network resource is neither on the first list or the second list (and where applicable, not on a third list of previously requested unmatched network resources), and is instead, a new unmatched network resource, gateway303initiates a data clutch process by which browser301can access the unmatched network resource. As used in this disclosure, the expression “data clutch” encompasses a digital analogy to the clutch of a manual transmission vehicle, where in contrast to an automatic transmission, actuating the transmission to change between gears has a manual, or user-provided component. In certain embodiments according to this disclosure, while portions of accessing an unmatched network resource proceed automatically, for the process to occur, similar to depressing the clutch of a manual transmission vehicle, the process of accessing an unmatched network resource also entails a user-actuated component.

Referring to the illustrative example ofFIG.3A, a data clutch process comprises gateway303sending, at operation317a request for manual authorization to be displayed by browser301. According to certain embodiments, the request for manual authorization is provided as a page for display at the browser, the page comprising a confirmation of the unmatched network resource (for example, the domain name, URL or IP address of “Website A”) and a button or other object through which user309can, upon viewing the page at the browser, click on, or otherwise provide an input registering their authorization to access the unmatched network resource. According to various embodiments, at operation319, the request for manual authorization (in this case, an approval page) is rendered for display to user309by browser301.

While user309has the option of not actuating the data clutch process and denying the request to access the unmatched network presented by an approval page, in the non-limiting example ofFIG.3A, at operation321, browser301receives authorization from the user to access the unmatched network resource.

As shown in the explanatory example ofFIG.3A, at operation323, in response to receiving the user's authorization to access an unmatched network resource, browser301passes an approval request seeking approval to access the unmatched network resource to an authorization layer. In this non-limiting example, the authorization layer comprises API305and the backend systems maintaining one or more lists of identifiers of network resources and the user, group and global categorizations of the network resources (for example, categorizations of the network resources as allowed, blocked, or otherwise unmatched) for the internal network.

In various embodiments, at operation325, in response to receiving the approval request from browser301, the authorization layer or one or more APIs thereof (for example, API305) interfaces with a backend management system to add an identifier of the unmatched network resource specified in the approval request passed at operation323to a list of unmatched network resources maintained at the authorization layer. According to various embodiments, at operation325, the authorization layer may, in addition to adding an identifier of the unmatched network resource of the request, run or more scripts associated with the unmatched network resource, such as, logging the frequency of future visits to the unmatched network resource, or moving the identifier of the resource to another network administration list (for example, a blocked or allowed list) depending on the satisfaction of one or more predetermined conditions. Further, at operation325, the authorization layer ratifies the user's approval of the request to access the unmatched network resource.

As shown in the illustrative example ofFIG.3A, at operation327, the authorization layer passes the authorization layer's approval of the request to access the unmatched network resource. In some embodiments, the approval is provided as a flag (as used, for example, with the Chrome and Chromium browsers), switch or other command by which an outside application can programmatically trigger operations of browser301.

According to certain embodiments, the data clutch process concludes with operation327, and at operation329, browser301once again requests the unmatched network resource, or in this particular example, “Website A” by passing the request to gateway303. That is, the process of requesting the unmatched network resource of “Website A” picks back up from where it left off at operation315, wherein, at operation329, browser301passes the request for the same unmatched network resource to gateway303. At operation331, gateway303performs a comparison of an identifier of the network resource in the request of operation329against one or more lists of allowed, blocked or previously requested unmatched network resources.

However, due to the iteration of the data clutch process performed across operations311through327, the requested network resource now belongs to a third list, or “greylist” of previously unmatched network resources, which through operation325, has been mapped to a network security processes of the internal network. Accordingly, at operation331, when gateway303performs a second comparison of an identifier of the requested network resource against one or more lists of allowed, blocked or unmatched network resources, the identifier of the requested network resource corresponds to an item of at least one list of unmatched network resources. Responsive to the requested network resource being found on at least one list of unmatched network resources, at operation333gateway303passes the request for the unmatched network resource to unregulated network307.

Assuming that the unmatched still exists and receives the passed request, at operation335, the unmatched network resource (in this case, “Website A”) returns, via unregulated network307a reply to the request to gateway303. Depending on embodiments, gateway303may log, examine (for example, to check for malware or other unwanted content) the returned reply, or block (for example, if the reply does, in fact, contain malicious content) the reply from the unmatched network resource.

According to various embodiments, at operation337, gateway303passes the reply from the unmatched network resource to browser301for display to user309.

Implementing a data clutch process, such as described with reference to the non-limiting example ofFIG.3A, provides a number of technical and security benefits without imposing any meaningful processing loads at the networked machines hosting browsers (for example, browser301). Specifically, certain embodiments according to this disclosure prevent malware from making automatic requests for access to unmatched network resources (a common mechanism for the propagation of spyware and malware) undetected, as new requests for access to unmatched network resources trigger the data clutch process. Further, by implementing a data clutch process, certain embodiments according to the present disclosure put unmatched network resources “on the radar” of network administrators, who can consult the “greylists” of unmatched network resources (for example, a list updated at operation325) to provide a targeted, or specific change in network policy (as opposed to only limiting access to resources on an allowed list) when an unmatched network resource is discovered to be a source of malicious content. Still further, implementing a data clutch provides the technical and administrative benefit of not having to install, run and update a further layer of security software (for example, web filtering software) at the machine providing browser301, as the comparison and authorizations of the data clutch process can be performed by one or more servers operating as a gateway and authorization layer, which work together to send (or not send) a flag to browsers operating on devices of the network. For most (if not all) browsers, the processing load associated with receiving and interpreting a flag from the authorization layer is minimal.

While the illustrative example ofFIG.3Ahas been described with reference to a process that begins with a new request for an unmatched network resource (for example, at operation311) presented by a user to a browser, embodiments according to the present disclosure are not so limited, and the data clutch process can also be initiated by a browser (or other process of a machine on a managed or regulated network) attempting to reload or re-access a previously requested unmatched network resource. Referring to the non-limiting example ofFIG.3A, in some embodiments, an approval request is triggered at operation339, wherein a user or process of the machine implementing browser301instructs browser301to reload a currently displayed webpage.

Additionally, while the non-limiting example ofFIG.3Ahas been described with reference to an architecture in which gateway303sends the request for approval (for example, at operation317inFIG.3A) through browser301, and user submits their approval through the browser (for example, at operation321) the present disclosure is not so limited. In certain embodiments, the user's approval of the request to access the unmatched network resource can be mediated through any trusted device, not just a trusted device through which a user is attempting to access the unmatched network resource through browser301. As an illustrative example, a user may attempt to access an unmatched network resource through a browser (for example, browser301) executing on a first machine. However, instead of sending the request for approval back through the browser (for example, as in operation317), the gateway may send the request for approval to a second, trusted device, such as a user's mobile phone.

FIG.3Billustrates operations of a further example of implementing a data clutch in a network environment in which a user can provide inputs through two trusted devices. For convenience of cross-reference, elements ofFIG.3Bwhich are common toFIG.3Aare numbered similarly.

Referring to the non-limiting example ofFIG.3B, in this example, an additional device, second trusted device351has been added to the network context previously shown inFIG.3A. Thus, in the example ofFIG.3B, user309can interface with at least the following trusted electronic devices, a first device running the instance of browser301, through which the request for access to an unmatched network resource is initially made at operation313, and a second trusted device351, which is communicatively connected to gateway303and the authorization layer providing API305. According to some embodiments, the first device providing browser301and second trusted device351implement different or complementary user authentication mechanisms. For example, the first device may authenticate a user (or otherwise prevent unauthorized users from obtaining access) with a protected password, while second trusted device351authenticates a user based on a thumbprint or facial scanner. In this way, the overall security of the system and validity of approvals (for example, at operation321inFIG.3A) may be enhanced.

As shown in the illustrative example ofFIG.3B, at operation311, a user formulates a request for access to a resource maintained at a location on unregulated network307and presents the request through browser301executing on a first trusted device. In some embodiments, the user's request is presented as part of a web address, a uniform resource locator, or an IP address. According to various embodiments, the request for a network resource is passed from browser301to gateway303at operation313.

In the explanatory example ofFIG.3B, as in the example ofFIG.3A, at operation315, gateway303performs at least a first comparison of an identifier of the requested network resource against a first list of network resources, to determine if the identifier of the requested resource exists on at least one list of allowed network resources. In certain embodiments, the first comparison is performed against a set of hierarchically ordered lists defining the groups to which user309belongs (for example, a global list, a section list, and a list which is personal to user309). Further, at operation315, gateway303performs a second comparison of an identifier of the requested network resource against a second list of network resources to determine if the identifier of the requested resource exists on at least one list of blocked network resources. Again, in some embodiments, the identifier of the requested network resource may be compared against a plurality of hierarchically ordered lists defining the groups to which user309belongs. In some embodiments, at operation315, a third comparison of the identifier of the requested network resource against one or more lists of previously identified unmatched network resources is performed.

Responsive to the comparisons of the identifier of the requested network at operation315not producing any matches of items on lists of network resources previously categorized as blocked, allowed, or unmatched, in the illustrative example ofFIG.3B, at operation317a, an approval request is passed from gateway303to trusted second device351, and presented to a user authenticated by second device351at operation319a. According to some embodiments, the request is presented as a page viewable on a browser executing on second trusted device351. In other embodiments, the approval request is presented through a separate application (for example, a security or authentication application, such as Duo Mobile) on second trusted device351. According to various embodiments, upon receiving and viewing the approval request, user309has the option of approving or declining the request. Responsive to user309declining the approval request passed and presented at operations317aand319a, the process described with reference toFIG.3Bends.

Responsive to a user indicating (for example, by pressing a button provided through a security application executing on second device351) their approval of the request to access the requested network resource at operation321a, at operation323a, second trusted device351sends the approval request to the authentication layer providing API305. Subsequently, operations325-337inFIG.3Bproceed as previously described with reference toFIG.3A.

FIGS.4A through4Dcomprise a non-exhaustive set of examples of possible network architectures in which data clutch processes according to embodiments of this disclosure can be implemented. As shown with reference to the illustrative examples ofFIGS.4A-4D, embodiments according to the present application are extensible and flexible and can be implemented across a wide range of network architectures. For convenience of cross-reference, elements which are common to more than one ofFIGS.4A-4Dare numbered similarly.

Referring to the non-limiting example ofFIG.4A, a first architecture400for implementing a data clutch process is shown in the figure. While a data clutch process can, in some embodiments, be implemented without executing any additional software at the device providing the browser (for example, browser301inFIG.3A), embodiments according to the present disclosure are not so limited. As shown in the illustrative example ofFIG.4A, browser401(for example, an instance of browser301inFIG.3A), gateway403, and the API(s)405interfacing with an authentication layer, are all executing on a single machine407, which is communicatively connected to unregulated network409. According to certain embodiments, first architecture400may be a development architecture, such as used by a network administrator for configuring or testing an implementation of a data clutch process. According to other embodiments, first architecture400may be part of a backup or failsafe architecture, so that a data clutch process can still be implemented if a primary component (for example, a gateway server) of a multi-machine architecture goes down or is otherwise unavailable. Embodiments according to this disclosure include embodiments utilizing flexible architectures, in which the gateway and authorization layer functionalities can be moved across different machines, and as previously discussed, architectures in which user authentication is provided via a trusted machine other than the trusted machine hosting the browser through which an unmatched network resource is requested.

FIG.4Billustrates an example of a second architecture420for implementing a data clutch according to various embodiments of this disclosure. In some embodiments, architecture420is implemented for an enterprise having an internal network of managed machines, which access outside, unregulated networks through a secure web gateway411.

Referring to the non-limiting example ofFIG.4B, a first machine407of an internal, or managed network runs an instance of a browser401, through which requests and responses for unmatched network resources, and requests for user authorization (for example, as in operation317inFIG.3A) can be presented and received. In some embodiments, second architecture420is extensible, and first machine407is one of several machines running instances of browser401.

As shown inFIG.4B, first machine407is communicatively connected to a secure web gateway411. According to some embodiments, secure web gateway411comprises one or more servers (for example, server200inFIG.2) through which traffic between unregulated network409and machines of the internal, or managed network (for example, first machine407) passes. As shown in the illustrative example ofFIG.4B, in second architecture420, gateway403and authorization layer405are implemented as processes executing on secure web gateway411.

FIG.4Cillustrates an example of a third architecture430for implementing a data clutch process according to various embodiments of this disclosure. Again, for convenience of cross-reference, the elements of third architecture430, which have been previously described with respect to elements of other figures, are numbered similarly.

Referring to the non-limiting example ofFIG.4C, third architecture430builds upon second architecture420through the addition of a second trusted device413(for example, an instance of second trusted device351inFIG.3B) communicatively connected to gateway403executing on secure web gateway411. According to some embodiments, second trusted device413is a smartphone, tablet, or other device which has previously been associated with the registered user of browser401. According to various embodiments, second trusted device413implements one or more security processes (for example, a password-based login, or facial recognition) by which only the authorized user of browser401can use second trusted device413.

By establishing a communicative connection between second trusted device413and gateway403, third architecture430facilitates sending a request for manual authorization (for example, as shown in operation317ainFIG.3B) to the trusted device, and receiving the user's manual authorization (for example, as shown in operation321ainFIG.3B) through the second trusted device. In this way, third architecture430leverages the security features (for example, password protection, or biometric authentication sensors) of the second trusted device to enhance the overall security of the data clutch process.

FIG.4Dillustrates an example of a fourth architecture440for implementing a data clutch process according to some embodiments of this disclosure. As shown by the non-limiting example ofFIG.4D, embodiments according to this disclosure are readily extensible, and the underlying processes can be scaled across multi-machine architectures. For convenience of cross-reference, elements shown inFIG.4Dthat are common to, and described with reference to other figures of this disclosure are numbered similarly.

Referring to the non-limiting example ofFIG.4, a larger scale implementation of an architecture for providing a data clutch process is shown in the figure. As shown in this illustrative example, there are three clusters of user machines (designated407A through407E), wherein each cluster has one of three server machines (for example, gateway servers411A through411C) acting as a secure web gateway for each cluster of machines. As shown in the explanatory example ofFIG.4, the browser-gateway-authorization layer-unregulated network architecture has been extended to comprise three instances (for example, gateways403A-403C) of the gateway process. Similarly, in the illustrative example ofFIG.4D, the suite of APIs405of the authorization layer are running on a standalone secure access server415(for example, a server such as described with reference toFIG.2).

While examples of implementations of a data clutch process in networks embodying extended or varied architectures have been described herein with reference to embodiments in which operations of the data clutch process are distributed among different combinations of machines belonging to the internal or regulated network, the present disclosure is not so limited, and contemplates embodiments in which operations of either the gateway or authorization layer are performed by one or more cloud computing platforms connected via a secure communication link to the devices and browsers generating requests for unmatched network resources.

FIG.5illustrates operations of an example of a method for implementing a data clutch process according to various embodiments of this disclosure.

Referring to the non-limiting example ofFIG.5, at operation505, a first device (for example, device100inFIG.1), or process thereof (for example, browser301inFIG.3A) receives a first request for access to a network resource (for example, a webpage, file transfer protocol site), wherein the first request comprises an identifier (for example, a domain name, URL, or IP address) of the requested resource. In some embodiments, the request at operation505is received as a user input (for example, entering a webpage address into a browser). In certain embodiments, the request at operation505is received programmatically, for example, by an application passing a flag to a browser executing on the machine.

According to various embodiments, at operation510, the first request is passed to a gateway (for example, gateway303inFIG.3A, or gateway403C inFIG.4D). In some embodiments (for example, in first architecture400inFIG.4A), passing the first request comprises a call from one application executing on a machine to another application executing on the same machine. In certain embodiments, passing the first request at operation510comprises sending the first request, including the identifier, to another machine (for example, secure web gateway411inFIG.4B).

As shown in the explanatory example ofFIG.5, at operation515, the gateway performs a comparison (for example, the comparison shown at operation315inFIG.3A) of the first identifier against a first list, comprising identifiers of “allowed” or approved network resources, and a comparison of the first identifier against a second list, comprising identifiers of “blocked” or prohibited network resources. Further, in certain embodiments, the gateway also compares the first identifier against a third list of identifiers of previously requested unmatched network resources (for example, as described with reference to operation331inFIG.3A). Depending on embodiments and configurations, operation515may be iterated across a hierarchical set of first and second lists, comprising top level lists specifying “allowed” and “blocked” network resources applicable to all network users, intermediate level lists specifying network resources that may be allowed or blocked for a particular group or tier of users, and then a bottom-level list of sites which are specifically allowed or blocked for a particular user.

Referring to the illustrative example ofFIG.5, at operation520, responsive to determining that the first identifier does not match any members of a first list of allowed network resources, nor does it match any members of a second list of blocked network resources, the gateway initiates a data clutch process according to certain embodiments of this disclosure, by which a user is made aware of the unmatched status of the requested network resources, and in some embodiments, the unmatched network resource is mapped to the security procedures of the network. According to various embodiments, at operation520, the gateway initiates the data clutch process by sending, to a trusted device associated with the user of the machine submitting the first request, a request for manual authorization to access the unmatched network resource. According to some embodiments, the trusted device is the device from which the first request was passed at operation510to the gateway. In some embodiments, the trusted device is a second device (for example, a user's smartphone or smartwatch) with separate or complementary (for example, if the first trusted device uses password protection, and the second trusted device uses a fingerprint scanner) user authentication to the first device.

As shown in the illustrative example ofFIG.5, at operation525, manual authorization to access the unmatched network resource is received from the trusted device. In some embodiments, at operation525, a user registers their authorization to access the unmatched network resource through the browser (for example, browser301inFIG.3A) through which they initially requested access to the resources. In various embodiments, at operation525, manual authorization is received as an input (for example, a touch on a touchscreen) at a separate authorization application presented on the trusted device.

According to various embodiments, at operation530, the manual authorization from the trusted device is passed to an authorization layer. According to certain embodiments, the authorization layer comprises one or more application programming interfaces for mediating the exchange of data between various actors of the internal network, such as browsers on networked devices, trusted external devices used for authentication (for example, trusted device413inFIG.4C), one or more gateways, and a back-end functionality embodying decision logic for permitting or denying requests for accessing network resources, and also maintaining lists of unmatched network resources. According to some embodiments, the authorization layer further comprises control logic for triggering one or more scripts (for example, a script logging subsequent accesses to a particular network resource) associated with managing access to unmatched network resources.

Referring to the non-limiting example ofFIG.5, at operation535, responsive to the approval request being received and approved at the authorization layer, the device or application through which access to the unmatched network resource is requested (for example, browser301inFIG.3A) receives approval from the authorization layer. In certain embodiments, the approval is provided as a flag or command to the requesting process to re-attempt the request for access to the network resource. In this way, certain embodiments according to the present disclosure are able to manage access to unmatched network resources without requiring the accessing devices to run additional applications or software. Thus, certain embodiments according to this disclosure enhance security without concomitant increases in processing loads at end-user machines.

Referring to the non-limiting example ofFIG.5, at operation540, the device or application presenting the first request, accesses the requested network resource (for example, as shown in operations333-337ofFIG.3A.