Patent Description:
A majority of data on an external network is accessed through a web application, such as a web browser a web app. Security for a compute device that requests the data is provided by software on the compute device. Typically, the software is part of the web application, operating system (OS), or firewall of the compute device. This security is limited in its flexibility and the user of the compute device is in charge of the security provided. The owner of the data being accessed has no control over the security after the data has left their database.

<CIT> dislcoses a gateway to a zero trust network that applies an access control policy to an endpoint device attempting to access a cloud-based application hosted by the zero trust network. The gateway acts as a reverse proxy between the endpoint device and the cloud-based application, based on the access control policy applied to the endpoint device. The gateway captures telemetry data regarding application traffic reverse proxied by the gateway between the endpoint device and the cloud-based application. The gateway detects an anomalous behavior of the application traffic by comparing the captured telemetry data to a machine learning-based behavioral model for the application. The gateway initiates a mitigation action for the detected anomalous behavior of the application traffic.

In an aspect, the present disclosure provides a computer-implemented method for zero trust endpoint network security, ZTENS, the method comprising: providing, by a ZTENS device communicatively coupled to a compute device, over a wired or wireless first communication channel, and through a web application of the compute device, first data indicating the ZTENS device is communicatively coupled to the compute device; providing, by an application of the ZTENS device, over the first communication channel through the web application of the compute device, directly using the web application for presentation to the user, and without any web server intervention, a list of one or more uniform resource locators, URLs, that are accessible only through the ZTENS device; receiving, by the ZTENS device and over the first communication channel, data indicating a URL of the one or more URLs selected by a user of the compute device through the web application; communicating, by the ZTENS device and over a wired or wireless second communication channel, the second communication channel different from the first communication channel, a request for website data of a website associated with the selected URL; and receiving, by the ZTENS device and over the second communication channel, the website data and providing the website data to the compute device, wherein the ZTENS device comprises a security circuity configured to provide intrusion detection and/or prevention for communications to or from the ZTENS device.

In another aspect, the present disclosure provides a non-transitory machine-readable medium including instructions that, when executed by a zero trust endpoint network security, ZTENS, device, cause the ZTENS device to perform operations for ZTENS, the operations comprising: providing, by the ZTENS device communicatively coupled to a compute device, over a wired or wireless first communication channel, first data indicating the ZTENS device is communicatively coupled to the compute device; providing, by an application of the ZTENS device, over the first communication channel and to the web application of the compute device, directly using the web application for presentation to the user, and without any web server intervention, a list of one or more uniform resource locators, URLs, that are accessible through the ZTENS device; receiving, over the first communication channel, data indicating a URL of the one or more URLs selected by a user of the compute device through the web application; communicating, over a wired or wireless second communication channel, the second communication channel different from the first communication channel, a request for website data of a website associated with the selected URL; and receiving, over the second communication channel, the website data and providing the website data to the compute device, wherein the ZTENS device comprises a security circuity configured to provide intrusion detection and/or prevention for communications to or from the ZTENS device.

In yet another aspect, the present disclosure provides a system for zero trust endpoint network security, ZTENS, the system comprising: a compute device including a user interface, communications circuitry, and a web application; a ZTENS device communicatively coupled to the compute device through first and second wired or wireless communication channels of communications circuitry and through the web application, the ZTENS device including security circuitry and the communication circuitry, wherein the security circuitry is configured to provide intrusion detection and/or prevention for communications to or from the ZTENS device, the ZTENS device configured to: provide, by the communications circuitry, first data indicating the ZTENS device is communicatively coupled to the compute device; provide, by an application of the ZTENS device, over the first communication channel, and through the web application, directly using the web application for presentation to the user, and without any web server intervention, a list of one or more uniform resource locators, URLs, accessible through the ZTENS device; receive, over the first communication channel, data indicating a URL of the one or more URLs selected by a user of the compute device through the web application; communicate, over the second communication channel and to a web server, a request for website data of a website associated with the selected URL; and receive, over the second communication channel, the website data and provide the website data to the compute device through the web application.

<FIG> illustrates, by way of example, a diagram of an embodiment of a system <NUM> including a zero trust endpoint network security (ZTENS) device <NUM>. The system <NUM> as illustrated includes a compute device <NUM> operable by a user <NUM>. The compute device <NUM> can be communicatively coupled to an external network <NUM>. The compute device <NUM> can be communicatively coupled to the ZTENS device <NUM>. The ZTENS device <NUM> can be communicatively coupled to the network <NUM>. The network <NUM> is communicatively coupled to a web server <NUM>.

The user <NUM> can access functionality of applications or hardware of the compute device <NUM> through a user interface <NUM>. The user interface <NUM> can, for example, provide the user <NUM> with access to functionality or data through a web application <NUM>. The web application <NUM> can include a web browser, a web app (e.g., a mobile app or other application that accesses data or services on another network). The web application <NUM> is accesses functionality of hardware or software that runs on the web server <NUM> , unlike computer-based software programs that are run locally on the operating system (OS) <NUM> of the device <NUM>. Web functionality or hardware is accessed by the user <NUM> through the web application <NUM> using an active internet connection (provided by the ZTENS device <NUM>). Web functionality is programmed using a client-server modeled structure-the user <NUM> ("client") is provided services through an off-site server (web server <NUM>) that is hosted by a third-party. Examples of commonly-used web applications include: web-mail, online retail sales, online banking, data storage, and online auctions.

Typically, when the user <NUM> wants to access web functionality, the user <NUM> will enter a uniform resource locator (URL) into a web browser or launch the web application <NUM>. The web application <NUM> can then access functionality of a network interface <NUM> through an operating system (OS) <NUM>. The OS <NUM> provides applications, like the web application <NUM>, with access to functionality of hardware of the compute device <NUM>. Communications circuitry <NUM> of the network interface <NUM> is an example of such hardware.

The communications circuitry <NUM> can implement a wired, data port protocol, such as Ethernet (e.g., Ethernet RJ45 or the like), universal serial bus (USB), controller area network (CAN), serial peripheral interface (SPI), inter-integrated circuit (I<NUM>C), universal asynchronous transmit/receive (UART), firewire, or the like over a physical port or bus. The communications circuitry <NUM> can, additionally or alternatively, implement a wireless communication protocol, such as Bluetooth®, WiFi, or a cellular data communication channel, such as long term evolution (LTE), fifth generation (<NUM>), institute of electric or electronic engineers (IEEE) <NUM>), or the like, using a transmitter, receiver, or transceiver.

The OS <NUM> can issue a command to the network interface <NUM> that causes communication of a request for data corresponding to the URL. The network <NUM> can communicate with the web server <NUM> to retrieve the data of the URL. The web server <NUM> can return the data corresponding to the URL to the compute device <NUM> through the network <NUM>. The user <NUM> can then view the data corresponding to the URL through the web application <NUM>.

This process of accessing the data corresponding to the URL includes security risks. An adversary can intercept a communication between the compute device <NUM> to the network <NUM>. An adversary can intercept the communication between the network <NUM> and the web server <NUM>. The adversary can alter the data in the intercepted communication. The altered data can harm one or more of the compute device <NUM>, the network <NUM>, or the web server <NUM>. The altered data can spoof a domain name service (DNS) conversion of a URL to an internet protocol (IP) address, be a part of a distributed denial of service (DDOS) attack, include credential stuffing, or the like. The OS <NUM> and the web application <NUM> can include software or hardware configured to help mitigate these vulnerabilities, but no true solution for mitigation of these vulnerabilities is currently known. These vulnerabilities of the typical URL data access can be mitigated using the ZTENS device <NUM>.

The ZTENS device <NUM> as illustrated includes a web USB/web Bluetooth® application <NUM>. WebUSB and WebBluetooth are application programming interface (API) standards for securely providing access to USB or Bluetooth® devices from a web browser (through web pages). The WebUSB standard, for example, was published by the Web Platform Incubator Community Group.

The application <NUM> can launch when the user <NUM> communicatively connects to the ZTENS device <NUM> through the compute device <NUM>. The application <NUM> can cause the web browser <NUM> to show a home page of the ZTENS device <NUM>. The home page of the ZTENS device <NUM> can present services available from the ZTENS device. The user <NUM> can interact with the ZTENS device <NUM> through the web application <NUM>, such as by selecting an available service. The service can include a URL to a website accessible through (e.g., only through) the ZTENS device <NUM>.

The ZTENS device <NUM> further includes security circuitry <NUM>, communications circuitry <NUM> (similar to communications circuitry <NUM>), and a memory <NUM>. The security circuitry <NUM> provides intrusion detection and/or prevention, such as to help reduce a likelihood of communications intercept, spoofing, or other attack. The communications circuitry <NUM> provides wired and/or wireless communications capability to the ZTENS device <NUM>. The communications circuitry <NUM> can communicate with the compute device <NUM> or the network <NUM>. The compute device <NUM> can communicate with the network <NUM>, through the ZTENS device <NUM>.

Instead of relying on the security provided by the OS <NUM>, web application <NUM>, or other component of the compute device <NUM>, the user <NUM> can improve web security by using the ZTENS device <NUM>.

The application <NUM> can cause (through the communications circuitry <NUM>) the web application <NUM> to present a list of one or more acceptable URLs <NUM> (or links to acceptable URLs <NUM>) that when selected navigates, through the ZTENS device <NUM>, to the website corresponding to the selected URL. Communications to the ZTENS device <NUM> can be secured by security circuitry <NUM>.

The security circuitry <NUM> as illustrated includes a geo-fence application <NUM>, multi-factor authentication application <NUM>, personal identification number (PIN) <NUM>, cryptography <NUM> hardware and/or software, biometric <NUM> hardware and/or software, transport layer security (TLS) <NUM>, certificate authority <NUM>, and a random number generator (RNG) <NUM>. The security circuitry <NUM>, in general, provides intrusion detection and/or prevention for communications to or from the ZTENS device <NUM>.

The geo-fence <NUM> can include a global positioning system (GPS), Galileo, or other geo location circuitry configured to determine a location of the ZTENS device <NUM>. The geo-fence <NUM> can include rules defining locations at which functionality of the ZTENS device <NUM> is accessible and/or inaccessible. The geo-fence <NUM> can force the user <NUM> to only use the ZTENS device <NUM> in a specified geographic location.

The multi-factor authentication <NUM> can prohibit access to the functionality of the ZTENS device <NUM>, unless the user <NUM> can provide multiple forms of authentication. Examples of authentication include a password, PIN (e.g., the PIN <NUM>), biometric (e.g., fingerprint, iris or face scan, or the like, through the biometric <NUM>), a verification code sent to a personal electronic mail (email), phone, or the like, among others.

The PIN <NUM> can include a hardware interface, such as a keypad (e.g., on a touch screen) through which a PIN of the user <NUM> can be entered. The PIN <NUM> entry can help ensure that the user <NUM> is authorized to access functionality of the ZTENS device <NUM>.

The cryptography <NUM> can implement symmetric, asymmetric, or other cryptographic techniques. The cryptography <NUM> can include hardware or software cryptographic techniques. Symmetric cryptography is generally more secure than asymmetric cryptography and can be preferred. In symmetric cryptography, a single key is used to encrypt and decrypt data. In asymmetric cryptography a private key is used for encryption and a public key is used for decryption. It is possible to determine a private key based on the public key, thus making asymmetric cryptography less secure. The symmetric cryptography can be implemented using a secure RNG <NUM>, a password, or code. Examples of symmetric encryption include advanced encryption standard (AES), data encryption standard (DES), international data encryption algorithm (IDEA), or Rivest cipher (RC) (e.g., RC4, RC5, or RC6). Secure socket layer (SSL) and transport layer security (TLS) <NUM> are example protocols (used by hypertext transport protocol secure (HTTPS)) that implement asymmetric cryptography protocols. Rivest-Shamir-Adleman (RSA), Diffie-Helman, Elliptic-curve cryptography (ECC), El Gamal, and digital signature algorithm (DSA) are examples of asymmetric cryptography protocols.

The biometric <NUM> hardware and/or software can be accessed through a user interface <NUM> through which the user <NUM> provides biometric data. The biometric <NUM> hardware and/or software can perform an iris scan, a face scan, a fingerprint scan, or the like of the user <NUM>. The memory <NUM> can include expected biometric <NUM> data of the user <NUM> from a previous biometric scan. The biometric <NUM> hardware and/or software can be used to help guarantee that only an authorized user accesses functionality of the ZTENS device <NUM>.

A certificate authority <NUM> issues digital certificates certifying the ownership of the cryptography key <NUM>. The certificate authority <NUM> allows the manage of the web server <NUM> that hosts the website on the acceptable URLs <NUM> to certify ownership of the cryptography key <NUM>. The certificate authority <NUM>, along with TLS/SSL <NUM>, can enable HTTPS communication between the compute device <NUM> and the ZTENS device <NUM>.

The memory <NUM> can include a acceptable URLs <NUM> of one or more websites (in the form of URLs) that can be accessed through the ZTENS device <NUM>. The acceptable URLs <NUM> can include websites that include information that is more sensitive than usual. Examples of such websites include personal or business banking websites, medical record websites, utility service websites, insurance websites, government websites, internal revenue service (IRS) tax filing, covert communications, or the like. The ZTENS device <NUM> can include a replacement for a virtual private network (VPN). The memory <NUM> can include proxy data <NUM> that can be used to hide an actual IP address of the compute device <NUM> or the ZTENS device <NUM>.

The DNS data <NUM> can associate, for each website of the acceptable URLs <NUM>, a URL with an IP address. The DNS data <NUM> can take the place of the normal DNS server access, and thus eliminates any vulnerabilities associated with such normal DNS server access.

The crypto key <NUM> includes one or more symmetric or asymmetric cryptography keys. The crypto key <NUM> can be used by the cryptography <NUM> hardware and/or software to encrypt or decrypt data of a communication.

The communications circuitry <NUM> implements one or more different communications protocols <NUM>, <NUM>. The communications protocol can include a protocol discussed regarding the communications circuitry <NUM>. The communications circuitry <NUM> can be configured to communicate with the compute device <NUM> using the first communications protocol <NUM> and the network <NUM> using the second communications protocol <NUM>. The application <NUM> can allow the user <NUM> to interact with the ZTENS device <NUM> over Bluetooth®, USB, or other communication protocol, through the web application <NUM>.

The communications circuitry <NUM>, in some embodiments, can parse a communication to a single endpoint (e.g., the web server <NUM>) into two or more disjoint packets. The communications circuitry <NUM> can then transmit the disjoint packets of the multiple packets using two or more respective communications protocols. The communications circuitry <NUM> thus transmit a first portion of a communication using a wireless fidelity (WiFi), Ethernet, or cellular data communication channel (e.g., LTE, <NUM>, or the like) and a second, different portion of the communication using a different one of the wireless fidelity, Ethernet, or cellular data communication channel, for example. More portions and more communication protocols can be used.

The ZTENS device <NUM> can be issued by a host of a website accessible through the web server <NUM>. The host can restrict access to the website to only those users that can pass the security measures of the ZTENS device <NUM>. This allows the host of the website to manage the security required to access the website. Normally, the user <NUM> accesses the website with just the security of the web application <NUM> or the OS <NUM>. Requiring the protocols of the ZTENS device <NUM> for accessing the website puts the security of the website into the hands of the website host.

Further security can be provided by the ZTENS device <NUM> by implementing one or more of ephemeral IPv6 (or the like), net maneuver, port knocking, channel hopping, or the like. The ZTENS device <NUM> can include further enhancement using physical security measures (e.g., tamper evidence, tamper resistance, or the like). The ZTENS device <NUM> can provide a replacement for a common access card (CAC), such as a public key infrastructure (PKI) card, Yubikey card, or the like.

In use, the user <NUM> can connect the ZTENS device <NUM> to the compute device <NUM>. The user can input a PIN using the PIN <NUM>, biometric data through the biometric <NUM> hardware and/or software, a username, password, a certification code using the multi-factor authentication <NUM>, or a combination thereof to authenticate themselves and gain access to the ZTENS device <NUM>. Authentication is a process of verifying an identity of the user <NUM>. Passing authentication can allow the user <NUM> to access further functionality of the ZTENS device <NUM> through the web application <NUM>. The user <NUM> can issue a communication to the ZTENS device <NUM> through the web application <NUM>. The communication can initiate ZTENS device <NUM> capabilities (e.g., hardware, software, or a combination thereof). The ZTENS device <NUM> can inspect content from the compute device <NUM>, such as to detect malicious behavior or exfiltration of data. The ZTENS device <NUM> can transact with the network <NUM> using the communications circuitry <NUM>, such as after performing URL translation to IP address (using the DNS data <NUM>). The communication with the network <NUM> or the compute device <NUM> can be secured using TSL/SSL protocol <NUM>, certificate authority <NUM>, or the like. The ZTENS device <NUM> can receive content from the network <NUM> and detect malicious behavior or exfiltration of data (e.g., using a recurrent neural network (RNN) or the like). The ZTENS device <NUM> can provide content that passes inspection (e.g., by the RNN) to the web application <NUM> through the communications circuitry <NUM>. The user <NUM> has then accessed the content of the website through the ZTENS device <NUM>.

<FIG> illustrates, by way of example, a diagram of an embodiment of a method <NUM> for ZTENS. The method <NUM> as illustrated includes providing (by a ZTENS device communicatively coupled to a compute device, over a wired or wireless first communication channel, and through a web application of the compute device) first data indicating the ZTENS device is communicatively coupled to the compute device, at operation <NUM>; providing (by the ZTENS device and over the first communication channel through a web application of the compute device) one or more uniform resource locators (URLs), at operation <NUM>; receive (by the ZTENS device and over the first communication channel) data indicating a URL of the one or more URLs selected by a user of the compute device through the web application, at operation <NUM>; communicating (by the ZTENS device and over a wired or wireless second communication channel, the second communication channel different from the first communication channel) a request for website data of a website associated with the selected URL, at operation <NUM>; and receiving (by the ZTENS device and over the second communication channel), the website data and providing the website data to the compute device.

The method <NUM> can further include before communicating the request for website data, authenticating, by the ZTENS device, an identity of the user. The method <NUM> can further include, wherein authenticating the identity of the user includes receiving, by the ZTENS device, a personal identification number (PIN) or biometric scan data from the user through a user interface of the ZTENS device. The method <NUM> can further include, wherein authenticating the identity of the user includes using multi-factor authentication through the web application.

The method <NUM> can further include analyzing data from the compute device for malicious behavior or exfiltration of the data before communicating the request for website data. The method <NUM> can further include translating, by the ZTENS device, the URL to an internet protocol (IP) address using domain name service (DNS) data in a memory of the ZTENS device. The method <NUM> can further include parsing the request for website data into multiple packets, the multiple packets including different portions of the request for website data, and wherein communicating the request for website data includes communicating different packets of the multiple packets over different communication channels including the second communication channel and a third communication channel.

The method <NUM> can further include, wherein the second and third communication channels include different ones of a cellular data communication channel, a wireless fidelity communication channel, and an Ethernet communication channel. The method <NUM> can further include, wherein the first communication channel includes one of universal serial bus (USB) and Bluetooth operating using a webUSB or webBluetooth communication protocol. The method <NUM> can further include before providing the website data to the compute device, performing, by the ZTENS device, malicious behavior and exfiltration of data analysis on the website data.

<FIG> illustrates, by way of example, a block diagram of an embodiment of a machine in the example form of a computer system <NUM> within which instructions, for causing the machine to perform any one or more of the methodologies discussed herein, may be executed. In a networked deployment, the machine may operate in the capacity of a server or a client machine in server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

The example computer system <NUM> includes a processor <NUM> (e.g., a central processing unit (CPU), a graphics processing unit (GPU) or both), a main memory <NUM> and a static memory <NUM>, which communicate with each other via a bus <NUM>. The computer system <NUM> may further include a video display unit <NUM> (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system <NUM> also includes an alphanumeric input device <NUM> (e.g., a keyboard), a user interface (UI) navigation device <NUM> (e.g., a mouse), a mass storage unit <NUM>, a signal generation device <NUM> (e.g., a speaker), a network interface device <NUM>, and a radio <NUM> such as Bluetooth, WWAN, WLAN, and NFC, permitting the application of security controls on such protocols.

The mass storage unit <NUM> includes a machine-readable medium <NUM> on which is stored one or more sets of instructions and data structures (e.g., software) <NUM> embodying or utilized by any one or more of the methodologies or functions described herein. The instructions <NUM> may also reside, completely or at least partially, within the main memory <NUM> and/or within the processor <NUM> during execution thereof by the computer system <NUM>, the main memory <NUM> and the processor <NUM> also constituting machine-readable media.

While the machine-readable medium <NUM> is shown in an example embodiment to be a single medium, the term "machine-readable medium" may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions or data structures. The term "machine-readable medium" shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present invention, or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term "machine-readable medium" shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include nonvolatile memory, including by way of example semiconductor memory devices, e.g., Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Claim 1:
A computer-implemented method for zero trust endpoint network security, ZTENS, the method comprising:
providing, by a ZTENS device (<NUM>) communicatively coupled to a compute device (<NUM>), over a wired or wireless first communication channel, and through a web application (<NUM>) of the compute device, first data indicating the ZTENS device is communicatively coupled to the compute device;
providing, by an application (<NUM>) of the ZTENS device, over the first communication channel through the web application of the compute device, directly using the web application for presentation to the user, and without any web server (<NUM>) intervention, a list of one or more uniform resource locators, URLs, that are accessible only through the ZTENS device;
receiving, by the ZTENS device and over the first communication channel, data indicating a URL of the one or more URLs selected by a user of the compute device through the web application;
communicating, by the ZTENS device and over a wired or wireless second communication channel, the second communication channel different from the first communication channel, a request for website data of a website associated with the selected URL; and
receiving, by the ZTENS device and over the second communication channel, the website data and providing the website data to the compute device, wherein the ZTENS device comprises a security circuity (<NUM>) configured to provide intrusion detection and/or prevention for communications to or from the ZTENS device.