Mobile management system

Abstract

A mobile management method and system includes receiving a DNS query for a hostname from an application on a client, retrieving reputation data associated with the hostname from a local cache on the client, determining whether a policy associated with the hostname and reputation data associated with the hostname exist, and sending a network flow through a VPN tunnel to a server or from a local proxy on the client to a private or public network, or blocking the network flow based on the determined policy for the hostname.

Description

Technical Field

[0001] (Cross - Reference to Related Applications) This application is a non - provisional patent application claiming the benefit of U.S. Provisional Patent Application No. 63 / 009,830, filed on April 14, 2020, the entire disclosure of which is hereby expressly incorporated by reference herein.

[0002] The present invention relates to the field of network communication on mobile devices, and more particularly, to the combined practice of network security, network control, network performance management, and mobile device management.

[0003] More specifically, the present invention extends a set of applications that can act to include traffic sent outside the VPN tunnel by a traffic Mobility client on all platforms, and provides visibility and control to all network applications to apply policies and issue data for non - tunneling and tunneling traffic. The present invention also provides the ability to "bridge" DNS queries using other packets related to the resolved address and control all of their connections using name - based policy rules.

[0004] The present invention also provides the ability to process network traffic information via a machine learning algorithm and use the result to control traffic using policy rules. More specifically, the present invention relates to aggregating information collected using a statistical algorithm and processing the aggregated information via a machine learning algorithm to automatically detect unusual data transfers. More specifically, the present invention relates to aggregating information collected using a statistical algorithm and processing the aggregated information via a machine learning algorithm to automatically detect usage that is abnormal for a typical user of a device. More specifically, the present invention relates to the use of machine learning algorithms of variational autoencoders, undercomplete autoencoders, and overcomplete autoencoders for processing aggregated network traffic information without human supervision or pre-labeled data.

Background Art

[0005] Over the past few decades, mobile enterprise workers using mobile computing devices have become common. As they have been widely adopted, many enterprises have recognized the need for better visibility and control of network communications taking place on the mobile devices used by their mobile workers. Many enterprises have also recognized the need for greater flexibility in the way policy rules governing the processing of network flows are expressed.

[0006] Furthermore, until recently, enterprises have turned to more complex network monitoring systems to try to cope. Such systems have helped to mitigate problems by "scaling up" conventional methods, but still rely on statistical algorithms driven by human interpretation. As the number of computer applications that depend on computer networks continues to increase, that approach has become too cumbersome for the network administrators who depend on them, just as much as the more conventional methods from which they originated.

[0007] Historically, enterprises have looked to network performance management tools to assist in controlling the problems listed above. Unfortunately, most existing products in the market are designed for wired and wireless networks that are completely controlled by the enterprise. Also, most existing products that provide control over the network do so through centralized mechanisms, which can represent bottlenecks or choke points that degrade network performance and the user experience.

[0008] Recently, some VPN solutions have been used to provide visibility and control of mobile network communications for devices using public networks. However, here too, these VPN solutions can only monitor and control network flows transmitted through the VPN tunnel and cannot monitor and control network flows configured to bypass the VPN tunnel.

[0009] In addition, with the widespread adoption of mobile enterprise workers using mobile computing devices, enterprises have had to address the expansion of the management of the rules governing the control and visibility of mobile networks. For example, in the case of split tunneling rules (rules that manage which network flows are sent through a VPN tunnel and which network flows bypass the VPN tunnel), current industry practice is to define the rules based on network address, port, or some other information actually present in the packets of the network flow. However, it is often impractical for users of these systems to express split tunneling rules using network addresses. Generally, the most natural way to express split tunneling rules is to use hostnames (i.e., send all of xyz.com through the tunnel and send everything else outside the tunnel). And as the mobile workforce grows, the ability to easily express these types of rules, or to have rules automatically created or applied by an AI engine, becomes increasingly important.

[0010] In the market, many current VPNs support the function of defining a set of search domains. By configuring these search domains, name queries that match the configured search domain are sent to the VPN, and name queries that do not match bypass the VPN. One problem with this model is that the VPN loses visibility of name queries that do not match the search domain. However, name queries that match the search domain are specifically sent to the VPN's DNS server rather than the local network's name server. There is an unmet need to have visibility of all name queries from mobile devices without requiring that name queries be satisfied by a name server defined for the VPN itself while allowing this.

[0011] The need to monitor and control network communications from a mobile device when they are conducted over a public network and not sent via a VPN tunnel to a protected enterprise network has not yet been met in the market. Also, there are currently unmet needs for supporting visibility of all name queries generated on a device, for control to manipulate name queries either inside or outside a VPN tunnel, and for control to apply the same policy (inside / outside the VPN tunnel) to subsequent network flows that use the same address as the one where the name query was resolved. There are also unmet needs to monitor the data stream of network behavior collected on a mobile device for the purpose of automatically creating and applying customized network policy rules and reducing the burden on the people doing so.

[0012] To reduce the burden on network administrators, some network monitoring systems have recently started incorporating "machine learning" algorithms. Machine learning (ML) algorithms can "learn" patterns within a given set of data, as the name implies. And once "trained", ML algorithms can be used to identify when patterns are repeating or when a subset of data does not conform to the recognized patterns, thereby freeing network administrators from having to manually identify recognizable or unusual data patterns.

[0013] Even now, significant challenges still exist in applying ML algorithms, the most significant of which is the data required to train them. ML algorithms require large amounts of data, and most ML algorithms require target patterns to be identified within the data for proper training (in ML jargon, this is called "supervised learning").

[0014] Current network monitoring systems collect the necessary data volume by collecting metadata for each packet. This means that information about all packets transmitted and received across all networks to be monitored must be analyzed and recorded. This set of metadata, while smaller than the actual network packets, is not a negligible amount of data in terms of transmission and analysis.

[0015] Also, in order to utilize "supervised learning" ML algorithms, the network monitoring system needs to identify all target patterns within the data used for training, which places the burden back on the network administrator.

[0016] The market is still striving to efficiently apply ML algorithms in a way that minimizes human interaction. More successful network monitoring systems require the "interesting" parts of the data to be interactively identified by collecting large amounts of data and often using data sets of third parties where the "interesting" parts have been manually identified by the network administrator or are "attention-grabbing".

Summary of the Invention

[0017] In view of the above, embodiments are directed to systems and methods for integrating network security, network control, network performance management, and mobile device management.

[0018] Embodiments are directed to systems and methods that provide a data collection, control, and monitoring system with visibility into network flow data that can pass through a VPN tunnel but can instead be rewritten to the local network stack in a way that bypasses the VPN entirely.

[0019] In other embodiments, the system and method are directed to capturing all name queries on a mobile device, manipulating the name queries either inside or outside a VPN tunnel based on policy rules expressed using host names or partial host names with wildcards, tracking the name queries and mapping them to associated responses, storing the association of names and addresses from the queries and responses, and applying the same policy as applied to the original name query to flows that use the address from name resolution.

[0020] Embodiments are directed to methods and systems for capturing all network flows on a mobile device and for reintroducing the network flows back into the original network stack on the mobile device such that the network flows are avoided from being captured for further monitoring. The methods and systems utilize the manipulation of name query flows according to configured policies defined using full or partial host names, track responses to the name queries, and apply the same policy as used for the original name query to flows that use the address resolved by the name query. The methods and systems further include processing in real time a stream of collected data for the purpose of automatically creating and applying the most appropriate network policy rules based on the actual user and device behavior on the network and corporate goals.

[0021] In further embodiments, the system and method provide real-time monitoring of user and device network behavior data collected on a mobile device for automatically creating and applying network rules most suitable for the current environment.

[0022] In yet other embodiments, the method can be executed on a roaming client that moves between the same or different networks, including but not limited to WiFi, cellular network technologies such as WiMAX, 3G, 4G, 5G, and Long Term Evolution (LTE), and other wireless networks, and the system can be operable with the roaming client. As a non-limiting example, the client can roam between two networks A and B such that a DNS query is processed while a VPN tunnel is established on network A, but by the time a subsequent flow to the actual remote host occurs, the VPN tunnel is established on network B. This can also apply to the transmission of network flows to data gateways within a VPN server pool vs. the transmission of network flow metadata.Further information regarding mobile devices that roam on multiple different networks and maintaining the connection between a mobile device that roams via a VPN tunnel and a corporate network can be found, for example, in U.S. Patent No. 7,778,260; U.S. Patent No. 7,602,782; U.S. Patent No. 7,574,208; U.S. Patent No. 7,346,370; U.S. Patent No. 7,136,645; U.S. Patent No. 6,981,047; U.S. Patent No. 6,826,405; U.S. Patent No. 6,418,324; U.S. Patent No. 6,347,340; U.S. Patent No. 6,198,920; U.S. Patent No. 6,193,152; U.S. Patent Application Publication No. US2010 / 0046436; U.S. Patent Application Publication No. US2009 / 0307522; U.S. Patent Application Publication No. US2009 / 0083835; U.S. Patent Application Publication No. US2007 / 0206591; U.S. Patent Application Publication No. US2006 / 0203804; U.S. Patent Application Publication No. US2006 / 0187956; U.S. Patent Application Publication No. US2006 / 0146825; U.S. Patent Application Publication No. US20060046716; U.S. Patent Application Publication No. US2006 / 0023676; U.S. Patent Application Publication No. US2006 / 0009213; U.S. Patent Application Publication No. US2005 / 0237982; U.S. Patent Application Publication No. US2005 / 0002419; U.S. Patent Application Publication No. US2004 / 0264402; U.S. Patent Application Publication No. US2004 / 0170181; U.S. Patent Application Publication No. US2003 / 0017845; U.S. Patent Application Publication No. US2005 / 0223115; U.S. Patent Application Publication No. US2005 / 0223114; U.S. Patent Application Publication No. US2003 / 0120811; and U.S. Patent Application Publication No. US2002 / 0122394, the disclosures of which are hereby expressly incorporated by reference in their entirety.

[0023] In another non-limiting example, the method and system can be employed as a stand-alone solution or built on an existing VPN. As a stand-alone solution, the method and system can be configured to capture all network flows so that information about them can be collected, and then the method and system can write all network flows back to the local network stack. When built on an existing VPN, after reading the network flows to collect information, control over the network flows can be asserted, whereby some flows are rewritten to the local network stack, other flows are sent through the VPN tunnel, and other flows are blocked.

[0024] For a name query, a policy lookup occurs against (potentially wildcarded) hostnames from a local table, and then the name query is sent either through the tunnel, outside the tunnel, or blocked.

[0025] Since the policy can be dynamic and configurable by the user, it may be necessary to ensure that name queries can be sent to either the DNS server inside or outside the tunnel. One way to achieve this can be to proxy the name query and response to the appropriate server. Another way to achieve this can be to simply forward the name query packet and rely on the underlying operating system behavior to generate the name query packet to the appropriate name server.

[0026] The system must track name queries and responses so that it can apply the same policies applied to name resolution itself to the flows resulting from name resolution. In one embodiment, this name resolution cache can be used to "short-circuit" subsequent name lookups to the same name. In another embodiment, it may be advantageous to always resolve all queries to ensure that the local cache is kept up-to-date.

[0027] Furthermore, embodiments are directed to systems and methods that provide a data collection and monitoring system that centralizes and aggregates data and then uses the aggregated data to train and execute machine learning (ML) algorithms.

[0028] According to other embodiments, the system and method are directed to an ML algorithm that outputs the detection of possible data extraction by one or more computers based only on previously collected data, such that such detection is customizable by a network administrator with respect to overall sensitivity, and to applying the ML algorithm to a customizable group of computers.

[0029] In still other embodiments, the system and method provide for the generation of reports, notifications, and alerts based on the output of an ML algorithm.

[0030] In further embodiments, the system and method provide conditions for accessing one or more computer networks and / or conditions for restricting the use of the network by one or more computers based on the output of an ML algorithm.

[0031] An embodiment is directed to a mobile management method including receiving a DNS query of a host name from an application on a client, obtaining reputation data associated with the host name from a local cache on the client, determining whether there is a policy associated with the host name and reputation data associated with the host name, and transmitting a network flow to a server via a VPN tunnel or transmitting a network flow from a local proxy on the client to a private network or a public network or blocking a network flow based on a policy determined for the host name.

[0032] Furthermore, an embodiment is directed to a mobile management system including at least one database including a stored instruction set, and at least one processor coupled to the at least one database. The processor is configured to, by executing the stored instruction set, receive a DNS query of a host name from an application on a client, search for reputation data associated with the host name from a local cache on the client, determine whether there is a policy associated with the host name and reputation data associated with the host name, transmit a network flow to a server via a VPN tunnel or transmit a network flow from a local proxy on the client to a private or public network, or block a network flow based on a policy determined for the host name.

[0033] Furthermore, embodiments are directed to a mobile management method including at least sending network flow metadata to a collector on a client, sending the network flow metadata in the collector via a VPN tunnel to a VPN server pool, processing the network flow metadata to discover and detect events and states in the network, sending the discovered and detected events and states to the client, determining whether there is a policy associated with the discovered and detected events and states, and changing at least one of network usage or device behavior based on the determined policy.

[0034] Embodiments are directed to a mobile management system including a VPN server pool and a client device connectable to the VPN server pool via a VPN tunnel. The client device includes a reputation data store, a policy rule store, and a VPN policy engine coupled to perform a policy lookup based on a policy rule stored in the policy rule store for a host name and reputation data of the host name stored in the reputation data store. The VPN policy engine is configured to perform a policy lookup and based thereon, send a network flow to a server via the VPN tunnel, send a network flow from a local proxy on the client to a private or public network, or block the network flow.

Brief Description of the Drawings

[0035] FIG. 1 is an exemplary diagram of a client-server system in which, at a client, a determination is made whether to connect to a host via a protected tunnel or locally connect to the host via a private or public network based on policy rules and / or reputation data for the requested host.

[0036] Figure 2 is a flowchart of an exemplary operation of a client-server system.

[0037] Figure 3 is a sequence diagram showing the order of events from opening an application on a client to reporting network flow.

[0038] Figure 4 shows an exemplary embodiment of an on-premises server and / or a server in the cloud.

[0039] Figure 5 shows the more detailed operation of functions in a server.

[0040] Figure 6 shows a high-risk traffic audit dashboard for a visited website belonging to a category configured as malicious.

[0041] Figure 7 shows a legal liability dashboard for a website having a reputation determined to be a legal liability.

[0042] Figures 8 - 38 show other exemplary dashboards prepared by a reporting engine based on policy, host name, and / or reputation data.

[0043] Figure 39 shows an exemplary flowchart of network flow metadata or information processing of a machine learning workflow.

[0044] Figure 40 shows an exemplary flowchart showing how network flow information or metadata is processed into a specialized dataset.

[0045] Figure 41 shows an exemplary diagram showing an exemplary ML algorithm.

[0046] Figure 42 shows an exemplary diagram showing a machine learning workflow.

[0047] Figure 43 shows an exemplary diagram showing a machine learning algorithm.

[0048] Figure 44 shows an exemplary diagram showing an idealized variational autoencoder.

[0049] Figure 45 shows an exemplary system environment for implementing an embodiment of the present invention.

[0050] Figure 46 shows exemplary cached collector data stored as text data or JSON data.

[0051] Figures 47 - 80 show further exemplary dashboards prepared by a reporting engine based on policy, host name, and / or reputation data. Detailed Description of the Invention

[0052] The details presented herein are by way of example and for purposes of an exemplary discussion of embodiments of the present invention only, and are presented to provide what is considered to be the most useful and readily understood description of the principles and conceptual aspects of the present invention. In this regard, no attempt has been made to show structural details of the present invention in more detail than is necessary for a fundamental understanding of the present invention, and the description, together with the drawings, is to make apparent to those skilled in the art how some forms of the present invention may actually be embodied.

[0053] The mobile cloud performance, security, and cost management system according to the embodiment provides visibility and control to all network applications. This system can act to extend the set of applications whose application traffic Mobility clients can send traffic outside the VPN tunnel on all platforms, apply policies to both tunneled and non-tunneled traffic, and disclose data. Therefore, regardless of the mobile operating system, such as iOS, Android, Windows, Mac, etc., and regardless of whether the traffic of mobile users is tunneled or non-tunneled, policies can be reviewed and applied, and reports can be created and disclosed.

[0054] Monitoring remote network clients for technically and legally risky behavior is difficult because they are away from the enterprise network. Existing solutions rely on services running on gateway network devices such as routers. Partly due to their scalability requirements, these routers typically modify traffic based on security policies without advanced reporting. Remote clients can also be difficult to reference when associating with traffic because their source addresses can change more frequently than on-premises clients. This loose association increases the complexity of connecting an agent / client (user or device) to its network traffic and its reputation data.

[0055] Reputation data collected from the client activity to the VPN server can be fed to a security information and event management (SIEM) system, a reporting engine (or business intelligence engine), and / or the machine learning algorithms of a machine learning engine to quickly identify suspicious network behavior. Since the reputation data is collected at the time of the client's connection, the reporting engine can quickly identify dangerous network activity coming from the VPN client without any additional processing.

[0056] FIG. 1 shows an exemplary embodiment of a cloud management system. The exemplary system uses a client-server configuration. In a client 10, which can be a mobile device such as a laptop, netbook, smartphone, handheld device, workstation, PDA, iPad, tablet computer, etc., one or more applications can be stored in memory and executed by a processor. When executing an application 12, a socket 14 can be established to send data, and a DNS request or query for a host name can be sent from a TCP / IP (or local) stack 16 that transfers unprotected network traffic to a tunnel interface 18 of a virtual private network (VPN) client 20. The VPN client 20 evaluates all packets and includes a VPN policy engine 22, a DNS proxy 24, a VPN tunnel 26, a collector 28, a local proxy 30, a policy rule store 32, and a reputation data store 34. The VPN tunnel 26 can connect the client 10 and a VPN server pool 100 via a wired or wireless network, including cellular network technologies such as WiFi, WiMAX, 3G, 4G, 5G, and Long Term Evolution (LTE), as well as other wireless networks. The policy rules 32 can be stored as a memory table, while the reputation data can be stored in a local cache or reputation data store or cache 34, updated over time, or timed out otherwise. The local proxy 30 is provided to return packets to the local network stack so that the packets are protected from the VPN. The policy rule 32 and the reputation data store 34 can be stored in one or more memories and accessed by the VPN policy engine 22.

[0057] Whenever a DNS request packet with a host name is received by the VPN policy engine 22, the VPN policy engine 22 can search the reputation data store 34 for reputation data of the requested host name based on the policies from the policy rule store 32 and perform a policy lookup for the requested (potentially wildcarded) host name. If the host name can be resolved by the client, the resolved host name is returned to the application 12. If the host name cannot be resolved at the client 10, the DNS query is sent through the tunnel 26 via the DNS proxy 24 to be resolved to the VPN server pool 100, and a DNS response with the resolved host name is returned to the application 12. The VPN policy engine 22 searches the reputation data store 34 for the reputation of the requested host name. If the reputation data of the host is not found in the local cache (reputation data store 34), the VPN policy engine 22 can request the reputation data of the host from the VPN server pool 100 that may be located on-premises and / or on a server in the cloud and record the retrieved reputation data of the host in the reputation data store 34. This reputation data can include, for example, risk level, category, popularity, and potential security incidents noticed in the past. The VPN policy engine 22 can also enforce policy rules based on the DNS host name and reputation. When a policy exists, the packet is processed according to the policy, for example, to establish a connection to a server via the VPN tunnel 26 or to establish a local connection to a host via a public or private network, thereby bypassing the VPN tunnel.

[0058] Furthermore, to ensure that the local reputation data on the client is up-to-date, every time the VPN policy engine 22 looks at a DNS query, even if there is reputation data and established policies regarding the resolved host in the local cache, the VPN policy engine 22 requests and retrieves the reputation data for that host from the VPN server pool 100 and can store (or update) that data in a table, e.g., in the reputation data store 34 on the client 10, where the key is the host name and the value is the reputation data.

[0059] Therefore, in the embodiment, regardless of whether the policy rule related to the host exists in the VPN policy engine 22, the reputation data can always be searched. This can be advantageous in that the policy is dynamic and can change at any time, and the reputation cache is up-to-date for all hosts for which DNS queries have been made. Therefore, even when the VPN policy engine 22 does not discover a policy rule regarding the host name, the VPN policy engine 22 searches the reputation data regarding that host from the VPN server pool 100 and updates the reputation data in the local cache or the reputation data store 34. In particular, the DNS proxy 24 can resolve a packet request having a host name and send the host name to the VPN server 110 of the VPN server pool 100 via the VPN tunnel 26. The VPN server 110 can access a reputation data store 112 that can be a local cache within the VPN server pool 100. The reputation data of the resolved host name is returned to the client 10 via the VPN tunnel 26, the reputation data store 34 is updated, and the policy rule based on the reputation data retrieved from the VPN server pool 100 can be stored in the policy rule store 32 for the host. Based on this new policy, it is determined whether to establish a connection via the VPN tunnel 26, or to establish a connection to a private or public network outside the VPN tunnel 26, or to block the flow.

[0060] If the server does not have reputation data in the local cache for the resolved host, the VPN server 110 can query an Internet-accessible reputation service that can resolve, for example, the host name or URL to a reputation score. The retrieved reputation data can then be sent back to the VPN policy engine 28 via the VPN tunnel 26 so as to be stored in the reputation data store 34.

[0061] Regardless of whether the DNS request is resolved locally or via a server, if a response comes back, application 12 makes a new request to the actual remote host. At this point, another policy lookup can be performed within the VPN policy engine, and the evaluation data can also be checked. The activities of various processes can be collected or stored on the client by collector 28, preferably temporarily. That is, after VPN policy engine 22 processes the request packet and its associated evaluation data, VPN policy engine 22 notifies collector 28 of the packet and the evaluation. After VPN policy engine 22 processes the packet to the actual host, its associated evaluation data, and the determination of how to handle the packet, i.e., whether to connect via the local proxy, via VPN tunnel 26, or block it, VPN policy engine 22 notifies collector 28 of the packet, the evaluation, and the network flow metadata. Collector 28 can store cached data regarding client 10, such as data regarding the WiFi connection, data regarding the VPN tunnel, data regarding connections made via the VPN, etc., and can periodically flush this collector data to data gateway 114 of VPN server pool 100, which is the server-side data collection point.

[0062] Furthermore, in an embodiment, there may be no policy that matches a given flow, or the remote host may be unknown with respect to reputation. If there is no policy and the reputation cannot be retrieved, a default behavior, such as tunneling the flow to the VPN server pool, can be performed.

[0063] Non-limiting examples of cached collector data that can be stored as text data or JSON data are shown in FIG. 46.

[0064] The data gateway 114 receives network flow information and / or metadata from the downloaded collector data and unpacks or normalizes the downloaded data. The data gateway 114 can transfer the data to the data publisher 116, and the data publisher can instruct the reporting engine 118 to report or create a dashboard. The reporting engine 118 can, for example, prioritize and filter the application flow data using reputation data to present the overall cybersecurity posture of the network. The data publisher 116 can also send the data to the machine learning unit 120, and the machine learning unit 120 can use artificial intelligence and machine learning algorithms to update information based on what it learns. The machine learning unit 120 can be coupled to send alerts to the VPN server 110 to warn the client or to update the client's policy.

[0065] An exemplary flowchart of the operations of client 10 and VPN server pool 100 is shown in FIG. 2. Process 200 begins, for example, when an application on a browser selects a connection to a host by querying a host name at 201. The TCP / IP stack sends a DNS query packet to the VPN policy engine at 202. Next, the process determines at 203 whether there is a policy to block the connection to the host. If the policy blocks the host, the packet is dropped at 204. If the policy permits the host, it is determined at 205 whether the reputation of the host is in the local cache (reputation data store). If there is no reputation data for the host in the local cache, the reputation data for the host is requested from the VPN server pool of the server at 206. The VPN server pool searches for that information in its own reputation database and, if necessary, sends a query for reputation data to, for example, an external reputation service for the reputation data. The VPN server pool returns the retrieved reputation data for the host to the VPN policy engine, and the VPN policy engine transfers the network flow to the collector at 207 for recording. If the reputation data of the host is found in the local cache, the VPN policy engine transfers the network flow metadata (or information) to the collector at 207 for recording.

[0066] At 208, a determination is made whether to connect via a tunnel or via a local proxy. If connecting via a local proxy, at 209, the local proxy writes back to the local TCP / IP stack that the network flow is protected with the VPN enabled. If connecting via a tunnel, at 210, the packet is transferred to the server via the VPN tunnel.

[0067] An exemplary sequence diagram showing the order of events when an application is opened on a client according to an embodiment. This sequence diagram generally corresponds to the exemplary flowchart shown in FIG. 2. Specifically, sequence 300 starts at 301 when a DNS query transmitted when an application on the client is opened, which is received in the VPN policy engine, is transmitted. At 302, the VPN policy engine determines whether it can resolve the DNS query, whether there is a policy, and whether there is reputation data for the resolved host. If necessary, the VPN policy engine can transfer the DNS query to the tunnel at 303, send the DNS query to the VPN server via the tunnel at 304, or block the flow. Further, if necessary, the VPN policy engine can send a reputation request to the tunnel at 305 and to the VPN server via the tunnel at 306.

[0068] The VPN server can send DNS responses to the application at 307 and can send reputation responses to the VPN policy engine at 308. At 309, the application sends a request for a network flow to the VPN policy engine. Next, at 310, the VPN policy engine determines whether the network flow should go through the tunnel, through the local proxy for local connection to the public or private network, or whether the network flow should be blocked. Regardless of whether the existing policy requires the network flow to be directed through the tunnel or local proxy or to be blocked, the VPN policy engine records an event with the collector at 312. At 313, the data stored with the collector is sent to the data gateway either periodically or asynchronously. At 314, the data gateway instructs the data publisher to publish the received data, and at 315, the data publisher sends the data received by the data publisher to the reporting engine and the machine learning unit.

[0069] As shown in FIG. 4, a mobile management system or platform 400 having a cloud-based Mobility server 401 can be built for enterprises to facilitate safely optimizing and managing network deployments in cases where employees may be accessing cloud and on-premises applications and services outside the firewall, using networks not under the enterprise's management control, using devices often not issued by the enterprise, etc. The mobile management system 400 can be used in combination with a Mobility server 402 deployed on-premises or used alone, thus providing automated performance, threat defense, and cost control in lieu of the on-premises Mobility server 402. This provides a seamless mobile cloud management system with control and visibility over all device traffic directed to enterprise data centers, the cloud, and the Internet. In such a configuration, when a client 403 accesses an app 404 that does not send traffic over a VPN tunnel, i.e., when traffic is sent outside the VPN tunnel to a cloud-based application or the Internet, a reputation request is separately sent to the Mobility server 401 or 402 for a reputation query.

[0070] Accordingly, the mobile management system 400 is provided with the function of monitoring and controlling remote and mobile clients outside the firewall. This is particularly advantageous in that known systems require all traffic to pass through a server or proxy where network activity is analyzed and policies are enforced, while the mobile management system 400 analyzes and controls on the mobile clients 403 and servers 401, 402 and policy enforcement is performed on the client 403.

[0071] In an embodiment where data analysis is performed on servers 401 and 402, the policy trigger can be sent to client 403 for implementation. Further, Mobility server 401 can be formed by one or more servers and / or proxy servers residing in a cloud such as AWS, Azure cloud, etc., and Mobility server 402 can be formed by one or more servers and / or proxy servers residing on-premises. The system can provide diagnosis, visibility, and policy control for flows within the VPN tunnel, for example, using strong AES encryption, DES, or Twofish. Further, the system provides diagnosis, visibility, and policy control for flows outside the tunnel going directly to the cloud. This configuration improves performance by freeing up resources in the enterprise and eliminating the need to send all data back to the servers within the enterprise or the cloud.

[0072] As a non-limiting example, a cloud-based Mobility server 401 configured to provide a secure tunnel service that provides first-hop security by creating an encrypted tunnel between a client 403 and a tunnel server includes a data gateway that functions as a collection point for client application flow, performance, and security data. Further, the cloud-based Mobility server 401 can also provide a secure tunnel back to the customer / enterprise internal network by simply setting up another tunnel between the customer's private network and the cloud. The Mobility server 401 can also include a policy service that can push a Mobility policy to an attached client 403, an alert service that can push a Mobility alert to an attached client 403, and management alerts sent via SMS, email, syslog, SNMP. In an embodiment, the servers 401, 402 have the function of identifying an advertising server, preventing their connections to those servers for web browsers and applications, and pushing down policy rules to the client to prevent the connections. Further, a secure tunnel between the cloud server and the on-premises Mobility server 402 can be established to provide cloud server configuration and client authentication. Further, the on-premises network can connect to the cloud-based Mobility server 401 by using more commodity technologies such as, for example, an IPsec tunnel, instead of another Mobility server operating within the customer's on-premises network.

[0073] The Mobility server 401 can be implemented to improve a company's security and performance. In an embodiment, Mobility server policy actions and conditions can be provided to route specific application traffic to specific proxy servers. Further, the proxy server can support TLS to return to an on-premises server pool for configuration and management, and the mobile client 403 can include a policy that uses TLS to direct traffic to a specific proxy server. The mobile client 403 can support minimal encryption, compression, and roaming when routing application traffic to the proxy. The mobile client 403 operating with the proxy can support all forms of authentication and support simultaneous routing of traffic using pass-through, proxy, and VPN traffic for various applications. For example, the traffic of application 1 can be routed to the proxy, the traffic of application 2 can be routed to the on-premises Mobility pool, and the traffic of application 3 can be routed to pass-through traffic. In another example, the flow of the same application can be routed differently based on the remote host name so that it goes out to the local proxy when the application communicates with remote host A and goes through the tunnel when the application communicates with remote host B.

[0074] The system provides diagnostic information regarding the state of networks, devices, and applications, while the system server can be present on-premises behind a firewall and within the cloud. Servers 401, 402 may include a VPN server, an anomaly detection data monitor, a server with a dashboard, and a proxy server. The system provides a configuration where authentication is required before permitting network traffic. The system supports multiple elements of authentication. The system analyzes network devices such as applications, users, devices, networks, access points, routers, carrier networks, locations, destination servers, websites, and domains visited by users, and performs reputation and category lookups.

[0075] Figure 5 shows an exemplary operational diagram of a server according to an embodiment. The client 510 can be, for example, a computer, laptop, phone, tablet, etc., that can establish, transmit, and receive data to and from third-party servers and services 520 via a network. Further, the server 530 can be on-premises or within the cloud and includes a VPN server pool 531, a machine learning unit 532, and a reporting engine 535. Further, the machine learning unit 532 can include a data ingestion server 536, a data storage 533, and an analysis server 534.

[0076] As described above, the network flow from the client may be established via a tunnel such that the network flow 511 is established between the client 510 and the VPN server pool 531 and then from the VPN server pool 531 to the third-party server or service 520. Alternatively, based on a policy, the network flow 513 can be established outside the tunnel to connect the client 510 to the third-party server and service 520 via a local proxy.

[0077] However, while network traffic can pass through the tunnel or outside the tunnel, the network traffic information 514 is transmitted via the tunnel between the client 510 and the VPN server pool 531. This network traffic information may include collector data from the client and metadata regarding network traffic 511, 512, 513. Further, the VPN server pool 531 transmits the network traffic information 515 to the data ingestion server 536 and transmits the network traffic information of the data 516 to the reporting engine 535. The data ingestion server 536 transmits the network traffic information 517 to the data storage 533 for recording, and the analysis server 534 can read the network traffic information 518 from the data storage 533. The analysis server 534 can analyze the metadata using, for example, artificial intelligence and machine learning algorithms and send an alert 540 to the VPN server pool 531 if it discovers something to protect the client or enhance the operation of the client. The VPN server pool 531 can issue an alert 541 to the reporting engine 535. The VPN server 531 can also establish a connection for policy updates 542 to the client 510 via the tunnel.

[0078] Network flow information or data can be compiled within reporting engine 535 based on various categories of interest, such as website reputation, so as to be presented to administrators and users within the dashboard. As a non-limiting example, the reputation can be characterized by five risk levels for the dashboard, such as severe_risk, high_risk, medium_risk, low_risk, and unknown_reputation. Further, the system can classify each visited website. As non-limiting examples, for instance, abortion, drug abuse, adult and pornography, adware security, alcohol and tobacco, auction, botnet - security, business and economy, CDN, cheat, computer and internet information, computer and internet security, confirmed spam source - security, cult and occult, dating, dead site, dynamically generated content, educational institution, entertainment and art, fashion and beauty, financial services, food and diet, gambling, games, government, gross, hacking, hate and violence, health and medicine, home and family, hunting and fishing, illegal immigration, image and video search, internet communication, internet portal, intranet site, job search, keylogger and surveillance, kids, legal, local information, malicious URL and path - security, malware site security, marijuana, military, automobiles, music, news and media, nude, online greeting card, open HTTP proxy - security, parked domain, pay - to - surf, peer - to - peer, personal site and blog, personal storage, philosophy and political support.Phishing and other fraud - Security, private IP addresses, proxy avoidance and anonymity - Security, suspicious, real estate, recreation and hobbies, reference and research, religion, spam URLs - Security, search engines, sex education, shareware and freeware, shopping, social networks, society, sports, stock advice and tools, streaming media, swimwear and intimate apparel, phishing and other fraud - Security, social networks, society, sports, stock advice and tools, streaming media, swimwear and intimate apparel, training and tools, translation, travel, unconfirmed spam sources - Security, violence, weapons, web advertising, web hosting sites and web - based email, etc. There can be over 85 different categories such as these.

[0079] Users can configure a specific dashboard with categories of interest. As a non - limiting example, FIG. 6 shows a dashboard named "High Risk Traffic Audit" that can display inspected and classified malicious websites that have been accessed. Further, the system can include reputation - based policies to automatically block malicious sites and report instances of attempted deployments. Further, non - limiting examples can include a dashboard named "Legal Liability" as shown in FIG. 7, which can display all websites accessed for a specific category configured as "Legal Liability". Further, the system can include reputation - based policies to automatically block malicious sites and report instances of attempted deployments. These dashboards can also be configured according to the user's needs. That is, "Alcohol and tobacco" may be acceptable for public safety authorities but may be a problem for electric utilities.

[0080] Metadata collected on the client for visibility and control is reported by the mobile client for traffic within the VPN tunnel and traffic outside the VPN tunnel, for example, about users, devices, networks, applications, destination locations, destination servers, destination services, countries, locations, and websites. This metadata is used to perform anomaly detection and security (entity) behavior. The system can create policy triggers based on the results of this analysis. For example, the reputation of users, devices, networks, applications, destination locations, destination servers, destination services, countries, locations, and websites can also be calculated based on behavior. As a non-limiting example, the system can detect that a user is accessing a website not normally used by other users in the deployment and uploading a large amount of information, such as uploading data to Dropbox. This behavior creates alerts and policy triggers that can be paired with one or more policy actions and sent to the client, as discussed below. One such method for analyzing data can be machine learning algorithms such as regression, random forest, and neural networks.

[0081] Client policies enable administrators to configure policy triggers based on individual webs, categories, and risk levels. The policies can be configured on the server and pushed down to the client and can be enforced by the client. This is because the client is context-aware, that is, the client knows about the network, location, speed, application, user, etc., while the server does not. In highly mobile networks, the context and environment are constantly changing, so policy enforcement on the client is required.

[0082] As a non-limiting example, the policy trigger can include the destination website, destination server address and port, running application, protocol, network SSID / BSSID, network name (such as AT&T), network speed, IP address change, inside the geographical fence and outside the geographical fence. Further examples of policy triggers can be executed from anomaly detection data monitors, user reputation, devices, networks, applications, destinations, destination services, countries, locations, and websites. When the client detects that the policy has been activated, it executes related actions, such as blocking access to a website or bypassing the website by directly sending website traffic to a cloud service outside the VPN tunnel. Non-limiting examples of actions include, for example, sending an SMS, email or text to the administrator, presenting a pop-up or toast message to the end user, enabling advanced logging, blocking the access point, tunneling the application via the VPN, sending the application traffic outside the VPN, blocking the website, blocking the application, hiding the application interface, forcing the user to re-authenticate, forcing the user to re-authenticate using additional authentication factors, compressing, accelerating, enabling forward error correction, starting the application, starting the network diagnosis, and performing a network speed test. It is understood that one or more actions can be taken in response to the policy trigger to resolve the policy trigger.

[0083] Policy Example 1:

[0084] Policy triggers and actions can be combined. For example, when a user is on a cellular network outside the firewall and accesses a social media video website, a policy trigger is created that is resolved by blocking the website and presenting a message to the user upon access to the website. However, when the user is inside the firewall and accesses a social media video website, the policy trigger is resolved by allowing the user to access the website.

[0085] Policy Example 2:

[0086] The anomaly detection data monitor has determined that there are changes in user behavior sufficient to require the end user to perform multi-factor authentication. The policy trigger is sent to the client and the multi-factor authentication process is initiated. Network traffic can be blocked until completion. A non-exhaustive list of examples of changes in user behavior can include location, network, device, application, and destination.

[0087] Policy Example 3:

[0088] Policy triggers regarding risk levels can also be supported. One example could be to create a policy action that blocks sites with a "high risk" or worse reputation.

[0089] Policy Example 4:

[0090] Blocking websites by category. One example could be to create a policy action that blocks all sports (sports being one of the categories) websites.

[0091] Policy Example 5:

[0092] The client system has the function of routing traffic to websites, applications, destinations, protocols, addresses, etc. When inside the VPN tunnel, the VPN can provide encryption. When outside the tunnel and sending directly to the destination, the application can usually provide encryption, such as when TLS / SSL is used when accessing an e-commerce site. When sending to a proxy service that can be on-premises or in the cloud, the client and the proxy can negotiate a TLS tunnel to provide encryption.

[0093] Policy Example 6:

[0094] In an extreme case, the policy may be configured to route all traffic outside the firewall. For example, all application and website traffic is configured to go directly to the cloud or the destination. In this case, the application takes the role of encrypting the traffic, while the VPN tunnel is used for management purposes of collecting metadata and providing policy control and configuration.

[0095] Policy Example 7:

[0096] In another extreme case, the policy can be configured so that all traffic is routed through the VPN tunnel.

[0097] Policy Example 8:

[0098] The policy may be configured to route traffic only through the VPN tunnel if the client determines that the underlying network is not secure. An example is when the client is roaming to a Wi-Fi access point without encryption configured.

[0099] Policy Example 9:

[0100] The policy may be configured to route traffic only via a VPN tunnel when the client determines that the underlying network is slow and compression and other optimizations are needed. An example of this is when the client is roaming on a network with a historical speed below some pre-set threshold.

[0101] Dashboards can be created from reports. As non-limiting examples, the system can look up destinations by location and report the location (e.g., country, city, etc.), and / or report on the use of VPN, network link quality such as network speed, SINR, RSRP, RSRQ, RSSI, and / or the active network by carrier or SSID / BSSID. Further, the system can report on the network used to access a particular website or server destination, the network used by a particular application, and / or the number of application usage bytes by application, device, and / or user.

[0102] The reporting engine can provide significantly improved filtering capabilities over known techniques by enabling the user to drill down into "User Details" and "Device Details". The dashboard with drilled-down user and device also links to other dashboards and retains the device and data / time context, making it much easier to investigate specific device-specific or user-specific data. In the non-limiting example shown in FIG. 8, by clicking on the "Mary Jones’ iPhone 6S" device within the VPN audit dashboard shown below, the user is directed to the "Device Details" dashboard of FIG. 9. Device Details shows device-specific information within the activity log table and activity map panel. The user can fan out from this dashboard to other dashboards while maintaining the "Mary Jones’ iPhone 6S" context by clicking on links to other dashboards. By clicking on a link to another dashboard, the "Mary Jones’ iPhone 6S" context and the selected time (24 hours) are maintained. In this example, the IP Location Audit link can be clicked within the dashboard drill-down panel to check whether Mary's device may be at risk. By clicking on the link, the IP Location Audit dashboard opens with the time and device information filters (see FIG. 10) automatically configured to maintain the context. Looking at Mary's application session activity, it can be seen that she was in Singapore and was performing suspicious activities that should be further investigated.

[0103] To analyze performance and network health, the dashboard in Figure 11 can be provided to administrators and managers to understand the overall mobile connectivity health and the most common issues experienced by mobile workers using cellular and Wi-Fi networks. This dashboard can show connection problems detected by Diagnostics and VPN problems reported or resolved by Mobility. Additionally, this dashboard can provide complete information when customers are running the Mobility client and Diagnostics client on their mobile devices. Administrators and managers can see from the dashboard how healthy the networks used by mobile workers are, whether the network health is improving or deteriorating, which users and devices are having connection problems, what the most common reasons for network connection failures are, what the most common reasons are for the Diagnostics connection report to report a failure, how often Mobility shields mobile workers from the adverse effects of connection problems, which devices are benefiting the most from running Mobility, and what the most common reasons are for workers to disconnect from the Mobility VPN.

[0104] The Network Bandwidth dashboard provides a statistical analysis of network throughput transmission, reception, and latency measured by mobile devices that are running Diagnostic bandwidth while connected to cellular, WiFi, and Ethernet networks. These dashboards can be configured to display statistical averages by default, but can also be configured to support median, maximum, minimum, 90th percentile, and 10th percentile. These dashboards can be populated by manual or automated bandwidth tests that operate on mobile devices with the Diagnostics client. The Cellular Bandwidth Summary by Carrier dashboard in Figure 12 can show what the actual throughput provided by a mobile carrier to an organization's devices is, whether the carrier's network provides sufficient throughput to run applications that require a certain level of throughput or latency (e.g., VoIP or real-time video conferencing), how much the carrier network throughput varies by time or day of the week, which carriers provide the best / worst throughput and latency, and whether the bandwidth on the carrier's network varies substantially between device manufacturers or models. Administrators and managers can use this information to understand when poor network performance is isolated or widespread in order to know whether to involve a carrier or device manufacturer, provide details of the performance issues observed with respect to a carrier or device manufacturer, and thus have sufficient information to diagnose, explain, and fix problems, understand when poor performance may be due to device or configuration issues (e.g., device drivers or antenna location), implement and deploy VPNs and applications designed to function well with our measured network performance, and make better informed decisions based on the information when contracting with a carrier or service.

[0105] The Cellular Bandwidth Summary by Cell Tower ID dashboard in Figure 13 can show which cell towers are providing the best / worst throughput and latency, whether there are consistently underperforming cell towers within the carrier's network, whether the performance of cell towers changes over time, which cell towers are most frequently used by mobile workers, and whether the throughput provided changes based on time of day or day of the week. Administrators and managers can use this information to provide carriers with specific information about tower performance so that they have enough information to diagnose, explain, and fix problems, advise mobile workers to switch to an alternative carrier or Wi-Fi when entering areas served by underperforming towers, deploy VPNs and applications designed to function well even when tower performance degrades, and make better informed decisions based on the information when contracting with carriers for service.

[0106] The Wi-Fi Bandwidth shown in Figure 14 can indicate what the actual throughput provided by the Wi-Fi network used by mobile workers is, whether the throughput provided by the Wi-Fi network varies based on time or day of the week, whether there is a Wi-Fi network that provides sufficient throughput to run mission-critical applications, which Wi-Fi network (SSID) provides the best / worst throughput and latency, whether there are access points (BSSIDs) with insufficient performance, and which are the most and least used access points in the Wi-Fi network. Administrators and managers can use this information to add or upgrade access points (BSSIDs) to improve coverage or performance, and deploy Mobility VPN and applications designed to function well even when the performance of the Wi-Fi network degrades.

[0107] The Ethernet Bandwidth Summary dashboard in Figure 15 can indicate how frequently mobile workers are using Ethernet instead of a wireless network, what the actual throughput provided by the Ethernet network used by mobile workers is, whether there is an Ethernet network that provides sufficient throughput to run mission-critical applications that require a certain level of throughput or latency, and whether there are significant variations in the mobile worker bandwidth test results on the Ethernet network. Administrators and managers can use this information to identify performance issues for mobile workers connecting using their wired home network, identify mostly office-based workers, and redeploy their devices to more mobile employees.

[0108] The Network Failures Summary dashboard in Figure 16 can assist managers and administrators in understanding why, when, and which employees' mobile network connections are down. For this dashboard, the reporting engine can use data from failed network connection attempts, failed Diagnostics reports, and networking losses lasting more than five minutes. The events reported in this dashboard can be obtained from mobile devices with a Diagnostics client and from manual or automated diagnostic reports. Using the network outage summary, it can be shown how frequently mobile workers experience long (longer than five minutes) connection losses, which network has been most disruptive to connections, whether there are any trends in connection disruptions and whether they are increasing or decreasing, which users, devices, and platforms are experiencing the most connection disruptions, whether connection disruptions occur more frequently at specific days / times, and the locations where connection disruptions occur. From this information, managers and administrators can quickly determine (a) that certain types of devices are experiencing more disruptions, (b) that applications are not the cause of connection disruptions, or (c) which networks are experiencing disruptions based on time and location, implement and deploy Mobility VPNs and applications operating within less reliable networks, purchase platforms with consistently fewer network outages, and make better carrier selection decisions based on the information, thereby shortening help desk call resolution times.

[0109] The Connect Failure dashboard can assist managers and administrators in understanding when and where a mobile device fails to connect to a Wi-Fi or cellular wireless network. In this dashboard, the reported events are obtained from mobile devices running the Diagnostics client. Connection failures can be presented for cellular (Figure 17) or Wi-Fi (Figure 18) connections. The Connect Failure dashboard can show when and on which devices cellular or Wi-Fi connection failures are occurring, whether there are devices experiencing more network connection failures than other devices, which users are experiencing the most network connection failures, on which cellular or Wi-Fi networks the most network connection failures are occurring, at which carrier, cellular tower, Wi-Fi network (SSID), or Wi-Fi access point (BSSID) users are experiencing frequent failures, and what can be done about this information. Using this information, managers and administrators can identify problematic coverage locations or devices within the Wi-Fi network, deploy patches or new devices to resolve problems, identify problematic coverage areas or towers within the carrier's network and provide detailed information to assist the carrier in troubleshooting and problem resolution, quickly determine that the application is not the cause of the connectivity problem, implement and deploy VPNs and applications that operate under these performance characteristics, improve deployments by purchasing platforms with consistently fewer connection failures, shorten help desk call resolution times by identifying network-related failures by time and location, and make better carrier selection decisions based on the information.

[0110] The Diagnostics Reports Summary dashboard in Figure 19 can be provided for administrators and managers who wish to view a summary analysis of diagnostic reports from mobile devices, understand the main causes of failures, and act accordingly. The events reported in this dashboard come from manual and / or automated diagnostic reports created by the Diagnostics client. This dashboard shows how many Diagnostics connection reports have failed / warned / passed, whether failures and alerts from Diagnostics connection reports are increasing or decreasing, what the results of the latest Diagnostics reports are, what the most common causes of alerts and failures are for a particular user or device or the entire mobile deployment, which users / devices are experiencing failures and alerts most frequently, and where the failures are occurring. Using this information, administrators and managers can shorten help desk call resolution times by identifying failures by time and location and digging into the causes related to specific users or devices, quickly determine the most common causes of connectivity issues related to the mobile deployment, identify problem devices and purchase a more reliable and less failure-prone platform, and implement and deploy VPNs and applications that operate under these performance characteristics.

[0111] The Realtime Traffic Audit dashboard in Figure 20 is part of threat defense. This dashboard provides a real-time snapshot for IT operations and security managers to see where client network traffic is currently originating and where it is headed, which countries, states, cities, IP addresses, and domains mobile devices are communicating with, and which users and devices are communicating. The events reported in this dashboard use the device locations reported by Diagnostics and the traffic flow destinations from the applications generated by Mobility. This dashboard can show whether there are devices exposing corporate data to risk or being exposed to risks threatening corporate security, what applications, websites, and servers the users are currently accessing, where the mobile network traffic is currently headed (country, state, and city), which devices are communicating with servers or resources outside the city or country, and which IP addresses and domains the mobile workers are communicating with. Using this information, administrators and managers can discover viruses and malicious applications on devices or risky behavior by mobile workers and then isolate or remediate the device / user.

[0112] The Traffic Destination Audit in Figure 21 is another threat defense dashboard. This dashboard provides IT operations and security managers with monitoring of Mobility client network traffic for destinations with detected issues using FQDN and IP address geolocation. It tracks application sessions with respect to devices, users, applications, destinations, FQDN, destination IP, and data volume. This report defaults to the last 24 hours but may be configured for a specific date range. For example, look at recent weekly or monthly behavior. Pushpins default to showing users but can be changed to show devices, applications, destinations, fully qualified domain names (FQDN), or destination IP addresses. Combined with the powerful filtering capabilities on the filter bar and within the pushpin popup, this dashboard provides a rich environment for security and data threat investigations. The events reported on this dashboard use the device locations reported by Diagnostics and the traffic flow destinations from applications generated by Mobility. Using this dashboard, it can be determined whether a user or application is sending or receiving data in an unexpected location, whether there are devices at risk of extracting corporate data, where current mobile network traffic is headed (country, state, and city), which devices, users, or applications are communicating with servers or resources outside the city or country, which IP addresses and domains mobile workers are regularly accessing, and which destinations have the most users, devices, and data. Using this data, administrators and managers can discover, for example, that an employee running the free personal version of Skype was communicating with a server in Russia and / or that a developer with a home Apple Mac running an application at risk of malware that was sending data to Asia.After the malware has been removed, the same report can be used to confirm that the device is not communicating with locations that are no longer permitted.

[0113] The VPN Security Audit in Figure 22 is part of the threat defense that enables IT managers to audit which devices and users are not using any VPNs, not just the Mobility VPN, in mobile deployments, and provides details about unsecured network access on cellular networks, Ethernet networks, and Wi-Fi networks. The report can be color-coded according to the risk level of the networks used without a VPN. Unsecured Wi-Fi networks and carrier networks that have the potential to cross the Internet are the least secure (shown in red) when used without a VPN. Networks with Layer 2 security accessed without a VPN are color-coded yellow. This report can be set to, for example, the most recent 24 hours by default, but can also be configured for a specific date range. By doing so, by clicking on the users or devices identified in the table to move to the "User Details" and "Device Details" dashboards, you can see when and where this occurred. The events reported in this dashboard can use data collected from the Diagnostics client. This dashboard can be used to determine whether there are users, devices, or data at risk because workers are connected to unsecured networks without a VPN, which Wi-Fi access points were used without a VPN, and which carrier networks were used without a VPN. Using this information, administrators and managers can identify policy changes to reduce corporate risk against man-in-the-middle attacks, TLS stripping attacks, and other malicious network threats, change the device configuration to enforce more secure mobile connection behavior among workers, lock down the system by configuring the Wi-Fi policy using MDM / EMM so that the VPN cannot be disabled, and conduct forensic analysis for a specific time period to identify where the lack of VPN use may have given malicious actors an opportunity to attack.

[0114] The VPN Status in Figure 23 is also part of threat defense for administrators who need to know whether users are currently connected to a secure or dangerous network without the protection of not only Mobility VPN but also any VPN. The VPN Status dashboard shows the real-time status of VPN usage across mobile deployments and identifies connections by devices and users not protected by a VPN. The status refresh intervals can be composed of 5 minutes, 10 minutes, and 30 minutes. The map shows active users running the Diagnostics client and is color-coded to facilitate identification. Green indicates that the VPN is active. Red indicates that the VPN is inactive. Events reported on this dashboard can use data collected from the Diagnostics client. This dashboard can be used to show whether many deployed users are currently using a VPN, where users who are not currently running a VPN are located on the map, which Wi-Fi access points were used without a VPN, and which carrier networks were used without a VPN. Using this information, administrators can identify policy changes to reduce corporate risk against man-in-the-middle attacks, TLS stripping attacks, and other malicious network threats, change the configuration of devices to implement more secure mobile connection behavior among workers, configure Wi-Fi policies using MDM / EMM to lock down the system so that the VPN cannot be disabled, and conduct forensic analysis for a specific time to identify where the non-use of the VPN might have given malicious actors an opportunity to initiate an attack.

[0115] The Wi-Fi Security Audit dashboard in Figure 24 is for operations staff and security staff who need to know where and when users are connecting to unsecured Wi-Fi access points. Users, devices, and access points can be identified by SSID and BSSID. Use the map to check the location of unsecured access points. Events within this dashboard can use data collected from the Diagnostics client. This dashboard can show which users and devices are accessing the Internet using unsecured Wi-Fi access points, which unsecured Wi-Fi access points were used, where unsecured access points were used, and how access point security changes over time. Using this information, operations staff and security staff can enforce VPN usage when users connect to the Wi-Fi network, configure strong encryption on enterprise-managed access points, lock down the system using policies to prevent the use of unsecured access points to protect against man-in-the-middle attacks, TLS stripping attacks, and other malicious network threats, configure Wi-Fi policies using MDM / EMM to change device configurations, and perform forensic analysis to identify where the use of unsecured Wi-Fi access points may have given malicious actors an opportunity to initiate an attack for a specific period of time and report on it.

[0116] The Mobility Impact Dashboard of FIG. 25 can be used for managers who need to understand and quantify, for cost control purposes, for example, the return on investment for wireless products and communicate it to executives and accounting staff. This dashboard can collect data over a predetermined period, for example, 30 days, and quantify disruptions, avoided security threats, saved production time, reduced application and network problems, and reduced network data. Further, the average of the fraction lost for each network disruption can be selected (e.g., 1 - 5). The data for this dashboard can be obtained from both the Mobility client and the Diagnostics client. This dashboard can show how many users are protected by Mobility, how much production time per day is avoided for each user over the last few days, for each network, how much traffic reduction results from data compression due to system persistence and compliance with roaming algorithms, how many disruptions are prevented by persistence and roaming, how many times the Mobility VPN protected a user while the user was on an unsafe Wi-Fi access point, how many application sessions are protected, optimized, and monitored for performance and threats, and how many network anomalies and threats are mitigated. Using this information, the manager can justify educating the manager and peers about the value of the product, purchasing similar products and renewing annual maintenance, and making better-informed investment decisions.

[0117] The Network Usage Report is for IT and network managers who need to understand the details of mobile network usage on carrier, Wi-Fi, and Ethernet networks. The events reported in this dashboard can use data collected from the Diagnostics client. These reports can be presented as Network Usage Summary, Cellular Network Usage, and WiFi Network Usage. The Network Usage Summary in Figure 26 provides an overview of data usage in a mobile deployment by user, device, and interface type. This dashboard can show what the internal roles of usage are for all network types, whether the usage of each type of network is increasing or decreasing, on which mobile platforms users are consuming the most / least data, how much data users are consuming on available networks, and who the top cellular data users are within the deployment. The Cellular Network Usage dashboard in Figure 27 is for managers who need to control cellular plan costs and understand the details of cellular data plan usage for specific carriers, devices, and users. This dashboard can show which carrier network the enterprise is consuming the most data on, which cell tower the device is connected to when it is sending the most data, whether carrier usage changes by time and day of the week, whether cellular data usage is increasing or decreasing, and which devices and users have the most / least cellular data consumption. The WiFi Network Usage dashboard in Figure 28 is for managers who need to understand data usage on private and public Wi-Fi hotspots for specific devices, users, and the Wi-Fi infrastructure.This dashboard can show which Wi-Fi network (SSID) the enterprise consumes the most data on, which access point (BSSID) the device is connected to when it sends the most data, whether Wi-Fi usage changes over time and day of the week, whether Wi-Fi data usage is increasing or decreasing, which users are using the access point, which devices and users consume the most / least Wi-Fi data, and when the Wi-Fi usage peak is and / or what the trend is.

[0118] The Cost Control dashboard for Application Usage provides IT, business, and security manager tools to understand application usage behavior over time by device, user, application, domain, and destination (FQDN or IP). These reports provide the ability to understand and analyze traffic patterns on devices that historically do not provide application-related information, including iOS iPhones and iPads. Events reported in the Application Usage dashboard can collect data from devices running the Mobility client. Filtering by specific device shows network data if the device is also running the Diagnostics client.

[0119] The Highest Application Usage dashboard in Figure 29 shows the timeline of the maximum data traffic and the 10 devices, users, applications, destinations, and domains with the maximum traffic over time. Filtering can be done down to a single device, and the timeline of the network used can also be displayed. A single device can be selected to specifically identify which applications and networks are being used. Also, the most frequently used ones can be identified by device, user, application, domain, and destination. This dashboard shows how data usage was over time, what the top 10 devices, users, applications, domains, and destinations were, when data usage occurred in terms of device, user, application, domain, and destination, which networks and applications were used by a specific device, which applications were used on a specific network in a specific device, whether there are usage anomalies for devices, users, applications, domains, and destinations within the time chart, which websites or domains the user is going to, and whether the user is going to unauthorized websites or domains when they should be working. Using this information, the system can prevent overage by using policies to block applications on specific networks, identify users and devices that can benefit from data usage policies, and deploy VPNs to reduce data consumption.

[0120] The Lowest Application Usage dashboard in Figure 30 shows the timeline of the lowest data traffic and the 10 devices, users, applications, destinations, and domains with the highest occurrence of the lowest traffic over time. Filtering can be done for a single device, and the timeline of the network used can also be displayed. By selecting a single device, it is possible to specifically identify which applications and networks are being used. It is also possible to identify the lowest usage by device, user, application, domain, and destination. This dashboard can show whether users are not making full use of their data plans, whether people are using the latest applications, which users are using the network the least, which applications are being used the least, and which destinations are being used the least. Using this information, users can consolidate their data plans by allocating different users to underutilized devices.

[0121] The Itemized Application Usage dashboard in Figure 31 shows details regarding all client application traffic protected by Mobility VPN. When filtered to a single device that also has Diagnostics, the user can view the timeline of the network used. This dashboard shows how data usage has been over time, what the top devices, users, applications, domains, and destinations are for data usage, where data usage has occurred in terms of devices, users, applications, domains, and destinations, which networks and applications have been used by a particular device, which applications have been used on a particular network for a particular device, what applications have been used on a particular network, what the usage anomalies are for devices, users, applications, domains, and destinations in the time chart, if there are unused data plans, if the latest applications are being used, which users are using the network the least, which applications are being used the least, and which destinations are being used the least. Using this information, the user can optimize data plans against usage patterns using policies, identify applications to block using policies on a particular network to prevent overuse, identify domains and destinations to block using policies on a particular network to prevent overuse, identify users and devices that can benefit from data usage policies, deploy a VPN to reduce data consumption, and consolidate data plans by allocating different users to underutilized devices.

[0122] For managers or support staff, the Devices dashboard in Figure 32 shows an inventory list of enterprise-owned devices. The dashboard supports filtering and sorting to quickly find a set of devices that match specific criteria or a single device. Clicking on a row in the table opens the Device Details dashboard for the selected device. To be displayed on this dashboard, a device must be running at least one Mobility software client connected to a server that supplies data to the reporting engine. The Devices dashboard displays any device running a Mobility client or a Diagnostics client. This dashboard can show how far along the enterprise's Mobility software rollout is, whether users need to upgrade the operating system or Mobility software running on their devices, whether there are devices not running both Mobility and Diagnostics, the number of devices running Mobility, which version of Mobility is being run, the number of devices running Diagnostics, which version of Diagnostics is being run, which operating systems and versions are deployed within the system, which users are using a specific device, how many different devices a single user is using, which operating systems and versions are deployed in the system, which platforms and operating system versions are running on the device, when the device was last used, and which devices have a phone number. Using this information, a manager can click on a device to go to the "Device Details" dashboard, find out which devices are not running both authorized Mobility products, install the client if necessary, and upgrade the device's Mobility software using an EMM / MDM system.

[0123] For managers or support staff, the User Dashboard in Figure 33 shows an inventory list of users with one or more mobility-enabled devices. The User Dashboard supports filtering and sorting to quickly find a set of users that match specific criteria or a single user. Clicking on a row in the table opens the User Details Dashboard for the selected user. Users are displayed who have a device that runs at least one Mobility software client connected to a server that supplies data to the reporting engine. The Devices Dashboard displays all devices that are running a Mobility client or a Diagnostics client. This dashboard can show how far the company's Mobility software rollout has progressed, how many mobile workers are running the Diagnostics software and which version, how many mobile workers are running the Mobility software and which version, whether there are devices that are not running both Mobility and Diagnostics, whether our users are using Mobility or Diagnostics, or both, how many different devices a single user is using, when a device was last used, and what the phone numbers associated with the user's devices are. Using this information, the manager can determine which devices are being used by the user, then click on that row to go to the User Details Dashboard, where they can analyze or troubleshoot performance, threats, or costs and redeploy devices that have not been recently used.

[0124] For managers and support staff who need to know where a device is, the Device Locator dashboard in Figure 34 shows the most recent location reported by each device that has run the Diagnostics client during that period. Pushpins can be color-coded based on how recently the location was updated. Clicking on a pushpin provides a popup with links to drill down into the device or user. Devices that are running the Diagnostics client are shown on this dashboard. The Devices dashboard shows all devices that are running either the Mobility client or the Diagnostics client. This dashboard can show where devices and users are, and whether there are devices that are reporting their location regularly. This information allows the manager to identify the most likely locations to start looking for a device that has been reported lost or stolen, and to identify devices that are being used far away from the areas assigned to the user.

[0125] The Cellular Adapter Status dashboard in Figure 35 is for managers and administrators who need to ensure that mobile devices have properly configured cellular adapters and that they are being used actively. Clicking on a row in the table opens the Device Details dashboard with information about all adapters associated with that device. Devices that are running the Diagnostics client are shown on this dashboard. This dashboard can show which devices do not have an active cellular adapter or have an adapter that is not configured correctly. Using this information, the manager can confirm that a device is properly configured before deploying it to a site where it could be costly to troubleshoot configuration issues.

[0126] The User Details dashboard in Figure 36 provides details of the devices associated with the user and the last known location of those devices. Managers and staff can use this dashboard to analyze user-specific details in any of the reporting engine dashboards related to performance, threat defense, or cost control. This provides a "fan out" starting point for rich analysis related to the selected user. Data can be collected for all Mobility clients or Diagnostics clients. This dashboard can show what devices, mobile platforms, and operating systems the user is using, what the user's device phone number is, what version of Mobility the user is running, what version of Diagnostics the user is running, when the user's device was last used, and where the last known location of this user's device is. Using this information, the manager can drill down into the devices used by the user to obtain more detailed information about the use and performance of those devices and drill down into the Mobile dashboard automatically filtered by the selected user.

[0127] The Device Details dashboard in Figure 37 can be used by managers and staff to obtain rich usage and performance information about a device. This dashboard is also a launch pad for analyzing a device's performance, threat defense, and cost control in any of the other reporting engine dashboards. The Device Details dashboard provides details of a single device, including device identification and configuration, network adapters on the device, users who used the device, the known last location of the device from the Diagnostics client software, a filterable activity log of recent events, an activity map of device movement and location during a selected period, a graphical timeline showing wireless network usage for all network adapters on the device, a signal quality timeline for each wireless adapter, and (for cellular networks only) a graphical timeline of the cellular network technology used. Data can be collected for all Mobility or Diagnostics clients. This dashboard can show who the device manufacturer is, which OS and version the device is running, which Mobility version the device is running, which Diagnostics version the device is running, who the user logged on to the device is, what the known last location of the device is, what network activity the device logged, when and where (on the map) the device connected, roamed, changed networks, disconnected, for devices that provide wireless statistics (Android and Windows), how the signal quality, SINR, and RSPR (Reference Signal Received Power) were over time, and whether the device has consistent LTE access and is downshifted on the carrier's network.Using this information, the manager can determine how and where the device is being used, obtain detailed information about the use and performance of that device, and drill down into the Mobile Dashboard automatically filtered by the selected device.

[0128] The Deployment Status Dashboard in Figure 38 is for managers and administrators who need to view the status of Mobility pools and servers that expose data to the reporting engine. Clicking on a row in the table opens the management console for the selected Mobility server. On this dashboard, a refresh interval is available to automatically refresh that information. This dashboard can show which Mobility pools and servers, and which Diagnostics servers, are providing data to the reporting engine, whether there are offline servers, how recently the servers have sent information to the reporting engine, and how many devices are licensed and active on each Mobility server. Using this information, the manager can confirm that the reporting engine system and related servers are operating correctly and receiving data from all possible sources.

[0129] The Application Details Dashboard in Figure 47 provides usage details for a single application identified by the application name. To identify the most relevant application data, a destination filter is used to focus the dashboard on application data sent to a specific destination. The dashboard panel includes information about the total data usage (GB), data within the VPN tunnel (GB), data outside the VPN tunnel (GB), data usage over time (GB), the number of different application versions reported by the device, the number of devices using each version, the devices and users who have used the selected application, and the network destinations (host names and IP addresses) it has contacted.

[0130] The Application Version Details dashboard in Figure 48 drills down from the Application Details dashboard. The Application Version Details dashboard identifies the users and devices running a specific application version.

[0131] The Application dashboard in Figure 49 shows high-level information about the applications used by the Mobility client in a deployment. Administrators can filter by device, user, and application. Click on a row in the table to view the full details, including the version of the application in use and data usage over time, as described in the Application Details dashboard. The total number of applications used by the Mobility client within the selected time frame is displayed at the top of the dashboard. The table shows the name of each individual application, the number of devices that used each application, the total amount of data sent and received by each, and the time when the application was last used by the Mobility client.

[0132] Traffic categorization is a feature of the Mobility Reputation service. When this service is enabled, the destination host name is categorized according to the site content, and a risk level is assigned based on an analysis of various factors including known malicious content and the popularity and longevity of the site. Each traffic category is assigned to a category group configured on the Mobility server. The Approved Traffic Destinations dashboard in Figure 50 has a pie chart and a table showing the number of application sessions (flows) by destination category within the Approved Traffic category group. On the right, a table is displayed showing the destination host names and the devices, users, and applications that contact them. If a destination belongs to multiple categories within the dashboard's category group, the number of times that flow occurs is added to each category.

[0133] The Batteries dashboard in Figure 51 provides insights into battery charging and discharging behavior and can be used to identify devices experiencing battery charging problems. This data can be useful not only for predicting the need for hardware replacement but also for troubleshooting. For example, by using this dashboard, an administrator can quickly determine whether a particular device or group of devices is exhibiting expected power usage behavior and take appropriate measures to replace or repair the battery. The dashboard filters enable the user to focus on the device batteries that the user wants to observe in the table.

[0134] The Category Details dashboard in Figure 52 is a dashboard dug down from dashboards of several category groups, namely, High Risk Traffic Audit, Legal Liability Traffic Audit, Approved Traffic Destinations, and Other Traffic Destinations. These dashboards require the Mobility Reputation service and are based on category groups configured on Mobility. This dashboard provides information about traffic destinations belonging to specific categories.

[0135] The Cellular Adapter Firmware Audit dashboard in Figure 53 reports the latest known firmware installed on the cellular adapters during deployment. Use this dashboard to monitor the current firmware version of the cellular adapters and identify potential conflicts when multiple firmware versions are being used by a specific cellular adapter model. The table shows, for each cellular adapter model, the total number of adapters of this model that are in deployment and the number of firmware versions these adapters are running. Use this table to identify the specific devices on which conflicting firmware is installed and the users associated with these devices.

[0136] The Cellular Adapters dashboard in Figure 54 displays the cellular network adapters present in the Mobility deployment. This dashboard focuses mainly on inventory and asset management rather than the performance / status of the cellular adapters. Use this dashboard to track over a selected time frame the progression of how many specific types / models of adapters are present in the deployment. This can reveal the technology trends within the organization and be useful for internal troubleshooting, inventory management, and purchasing decisions.

[0137] The Cellular and Wi-Fi Connection Map dashboard in Figure 55 compares cellular and Wi-Fi network usage from all Mobility clients that collected data during the selected time frame. Each grid cell that reported one or more connected devices is colored based on the percentage of Wi-Fi network usage in that cell. A color-coded map legend is used to identify cells for analysis. Areas with low Wi-Fi usage (less than 10%) may not have available Wi-Fi coverage. Areas with a mix of Wi-Fi and cellular usage are worth exploring to refine device usage policies and gain a better understanding of the Wi-Fi networks used by some devices. It is also worth investigating areas with a high percentage of Wi-Fi network usage, including the enterprise location. In these situations, if it is known that significant Wi-Fi coverage is available, it may be necessary to reconfigure devices that continuously use cellular networking within those areas. This dashboard includes a panel that displays summary information about Wi-Fi and cellular network usage within the selected cell.

[0138] The Cellular Bandwidth Tests dashboard in Figure 56 displays information about each bandwidth test that occurred during the selected time frame. The data panel shows the total number of completed and failed tests. The table of bandwidth tests provides additional information about each test run, including test results and statistics for device and user information, carrier information (carrier, cell tower ID, network technology, signal quality statistics, and RF band), and each throughput (download, upload, latency, trigger, comment, and failure message) measurement.

[0139] The Cellular Coverage Map dashboard in Figure 57 describes the cellular network infrastructure, i.e., which carriers are being used, what the signal quality is like, and the available technologies (e.g., 4G vs. 5G). The coverage map displays information aggregated from all Mobility clients that collected data during the selected time frame. To better understand the network performance in a specific area of the coverage map, look at the single-colored cells.

[0140] The Cellular Grid Cell Details dashboard in Figure 58 displays information about a specific grid cell selected from the Cellular Coverage Map dashboard. Dashboard filters such as home carrier, radio type, network technology, and technology generation are pre-added based on the filters selected on the Cellular Coverage Map. The dashboard panel includes the grid cell, the map coordinates of the cell being viewed, an approximate number of devices and users connected to the network within the specified grid cell, aggregated statistics reported by clients within the selected grid cell, signal quality statistics for the grid cell, and individual activity statistics for each device.

[0141] The Destination Details dashboard in Figure 59 displays information about network traffic destinations identified by host name or IP address. The table at the top of the dashboard shows when the destination was last accessed, how much data was used to communicate with it, and the total number of application sessions (flows) that contacted this destination. This dashboard can be filtered by device, user, and application, and if the Mobility Reputation service is enabled, it can be filtered by category and risk level.

[0142] Use the Device Activity Dashboard in Figure 60 to monitor when and where specific device activities occur (e.g., network changes, roaming, disconnections, or access to prohibited / malicious content as described in your device policy). Activity logs and maps trace the device's path through the selected time frame and report on its networking activity. To monitor the activity of specific network adapters used by the device, use the adapter filter to focus on the adapters for which you want to observe the activity logs and maps.

[0143] The Device Location Health Dashboard in Figure 61 is used to monitor the status of location reporting for devices in a NetMotion deployment. Identify devices that frequently drop location data, including both the percentage of times location data was successfully collected for each device and the number of location drops. This information can be used to determine whether a device is reporting location data when expected. Devices that frequently drop location data may need to be reconfigured, repaired, or replaced.

[0144] The Diagnostic Reports List Dashboard in Figure 62 displays a list of diagnostic tests generated in the deployment. Reports can be initiated manually by the user, automatically by the Mobility policy, or based on a schedule. If a user experiences networking problems, e.g., an application is not operating as expected or there is no network access, the user can generate a diagnostic report that helps identify the problem and provides possible troubleshooting solutions. Click on a report in the table to drill down to the Diagnostic Report Details Dashboard and view additional information.

[0145] The Ethernet Network Usage dashboard in Figure 63 provides interface - specific insights into the Ethernet network data usage by the Mobility client. The top - most statistics show how many devices used data via that interface type, the total data usage, and the usage over the past hour (including the trend per hour). The data usage on the time chart enables an assessment of when the most data was used. The table of data usage by device and user helps to evaluate who is using data on which device.

[0146] Traffic classification is a feature of the Mobility Reputation service. When this service is enabled, the destination host names are classified according to the site content, and a risk level is assigned based on an analysis of various factors including known malicious content, as well as the popularity and lifespan of the site. Each traffic category is assigned to a category group configured on the Mobility server. The Legal Liability Traffic Audit dashboard in Figure 64 has a pie chart and a table showing the number of application sessions (flows) by destination categories within the Legal Liability category group. On the right side of the table, the destination host names and the devices, users, and applications that contacted them are displayed. If a destination is in multiple categories within the dashboard category group, the flow numbers are added to each category.

[0147] The Licensing dashboard in Figure 65 displays Mobile IQ and Mobility statistics over the past 30 days covering licensed data usage, the total number of available client licenses, the client licenses in use, and the percentage of licenses used in your deployment. Mobility license information is segmented by pool if the deployment includes multiple pools.

[0148] The Mobile IQ Status Dashboard in Figure 66 provides an overview of the NetMotion Mobile IQ server, including inventory information and usage statistics. The inventory information includes the server operating system, the version of Mobile IQ running on the server, and the current console user. The usage information includes Mobile IQ disk space, details about the latest MIQ backup, CPU and memory usage, and the most recently accessed dashboards. Use this dashboard to ensure that the Mobile IQ server is running the appropriate software version and using the expected disk space, as well as to identify unexpected server resource usage.

[0149] The Mobility Alerts Dashboard in Figure 67 enables administrators to monitor alert conditions generated by the Mobility server and clients, including alert type, message, and inventory details. Server alerts are generated when a problem is detected in the Mobility server or pool, Mobility warehouse, or data publishing target. The table displays, for each server alert, the time of the alert, the server that generated the alert, and the alert type and message. Client alerts are generated when a problem is detected at the client level (such as a device connection failure) or when a preconfigured client threshold is exceeded (such as when a device using battery power falls below a preset limit). The table displays, for each client alert, the time of the alert, the device and user connected to the client, and the alert type and message.

[0150] The Mobility Connection Status dashboard in Figure 68 enables administrators to monitor the connection status of all devices in the deployment reported by the Mobility server. It identifies devices experiencing unexpected connection activities, such as devices that cannot connect to the Mobility server, unreachable devices, and devices that remain connected outside of working hours. This dashboard displays information about the device connection status from the perspective of the Mobility server. The connection status is updated at least every half hour while connected to Mobility. Other device statuses are not updated until they change.

[0151] The Mobility Disconnects dashboard in Figure 69 identifies devices disconnected from the Mobility server and provides the reason for the disconnection. This information is used to monitor when devices are disconnected from Mobility and to identify the users who are disconnecting them manually.

[0152] Traffic classification is a feature of the Mobility Reputation service. When this service is enabled, the destination host names are classified according to the content of the site, and a risk level is assigned based on the analysis of various factors including known malicious content and the popularity and lifespan of the site. Each traffic category is assigned to a category group configured on the Mobility server. The Other Traffic Destinations dashboard in Figure 70 has a pie chart and a table showing the number of application sessions (flows) by destination categories within the Other Traffic category group. On the right side of the table, the destination host names and the devices, users, and applications that contact them are displayed. If a destination is in multiple categories within the dashboard category group, the flow count is added to each category.

[0153] An isolated Mobility client device or user cannot connect to Mobility. Isolation can be applied to a device, user, or group. When an isolated entity (device, user, or group member) attempts to connect to Mobility, an isolated connection occurs. The Quarantined Connections dashboard in Figure 71 displays information including the device name, group membership, and last-connected Mobility server each time an isolation is reported, when the isolation was implemented. Isolation can be applied manually from the Mobility console or automatically initiated by devices that do not comply with network access control (NAC) rules.

[0154] The NetMotion Reputation Service configured within the Mobility console uses reputation categories, site history, age, rank, and location, in addition to other context and behavioral trends, to determine the risk level of destinations or applications accessed by Mobility clients. Each reputation category (such as Gambling or Violence) belongs to a larger category group (Legal Liability). These category groups are used by the Mobile IQ dashboards (High Risk Traffic Audit, Legal Liability Traffic Audit, Approved Traffic Destinations, etc.) to classify and analyze network traffic. The Reputation Category Groups dashboard in Figure 72 enables administrators to investigate the latest category group assignments without leaving the Mobile IQ console.

[0155] The SIM Cards - Last Used Plans dashboard in Figure 73 identifies data plans within a mobile deployment that have not been recently used and may be candidates for plan termination or redeployment to save costs. It tracks data plans by phone number, carrier, and other identifiable device information to determine which plans are inactive or in use. This dashboard does not have a time filter. Data is displayed for a full 90-day retention period to reveal the most complete data usage trends.

[0156] The SIM Cards - Low Plan Usage dashboard in Figure 74 reveals potentially underused data plans and enables organizations to make better use of existing mobile devices. Use this dashboard to identify cellular data services that can be canceled or redeployed to other mobile workers and to identify plans that can be better pooled together. The table sorts and lists SIM cards detected on the network within a selected time frame by lowest data usage. Use the time filter to focus on data for a specific time range, such as a cellular billing period. Additional inventory information is displayed to identify the devices and users associated with the SIM card. This information includes device and device groups, users and user groups, phone numbers, home carriers, IMSI, and ICCID.

[0157] The SIM Card Details dashboard in Figure 75 displays the inventory and usage statistics for a single SIM card, including its home carrier and other inventory information. See which devices, users, and adapters have connected using this SIM card and how much data has been used.

[0158] The Threat Status Dashboard in Figure 76 provides a high-level overview of potential security threats, including access to malicious servers and services, connections to low-security connections outside of Mobility VPN tunnels, and access to unsecured Wi-Fi networks. Each dashboard panel displays a high-level count for the corresponding threat category. If the count is greater than 0, the administrator can view some additional details, such as the timeline and the number of related devices. Each panel drills down to a dashboard with more details about that threat type.

[0159] The Traffic Destination List Dashboard in Figure 77 shows high-level information about the destinations (host names and IP addresses) contacted by Mobility clients in the deployment. This dashboard can be filtered by device, user, application, and destination. Click on a row in the table to view full details, including the timeline of data used while communicating with the destination, device, user, and application that contacted it, and a map of the related remote server location described in Destination Details. At the top of the dashboard, the total number of destinations accessed by Mobility clients during the selected time frame is displayed. The table below shows the host name or IP address of each destination, the number of devices that accessed each, the total amount of data sent and received by each, and the time when the destination was last accessed by a Mobility client.

[0160] The Wi-Fi Bandwidth Tests dashboard in Figure 78 displays information about each Wi-Fi bandwidth test that occurred during the selected time frame. The data panel shows the total number of completed and failed tests. The table of bandwidth tests provides additional information about each test run, including test results and statistics regarding device and user information, network information (BSSID, SSID, channel, and RSSI), and each throughput measurement (download, upload, latency, trigger, comment, and failure message).

[0161] The Wi-Fi Connection Map dashboard in Figure 79 illustrates the Wi-Fi infrastructure in a NetMotion deployment. It checks where devices connected to Wi-Fi and for how long, and identifies areas of poor network performance. The Wi-Fi Connection Map displays aggregated data from all Mobility clients from which data was collected during the selected time frame. Use the map legend to quickly compare total Wi-Fi device time across grid cells and identify potential problem areas by usage (users, devices, connections, and duration).

[0162] The Wi-Fi Grid Cell Details dashboard in Figure 80 displays information about a specific grid cell selected from the Wi-Fi Connection Map dashboard. Dashboard filters for SSID and BSSID are pre-added based on selections made on the Wi-Fi Connection Map. Clear these filters to view statistics for all Wi-Fi connections within the grid cell over the selected time frame. The panels within this dashboard display the viewed grid cell and its map coordinates, the approximate number of devices and users connected to the network within the specified grid cell, and the aggregated statistics reported by clients within the selected grid cell.

[0163] The systems and methods in the embodiments disclosed herein use artificial intelligence (AI) and machine learning to improve performance, reliability, cost, and security. In particular, the systems and methods maintain real-time entity behavior recognition, such as user, device, application, battery, network, domain, reputation, etc., by automating performance, cost, and security improvements in real time, and operate to perform cohort analysis to monitor group behavior in real time. AI and machine learning can similarly perform cohort analysis, i.e., identify entities that are not behaving the same as others, and perform entity analysis that can monitor changing usage patterns to determine when an entity is behaving anomalously. Further, the systems and methods can use statistical algorithms or machine learning algorithms, or combinations thereof, using data from groups of users, individual users, and / or discovered cohorts for purposes such as anomaly detection, cluster analysis, cohort discovery, pattern recognition, etc. Non-limiting examples of statistical algorithms and machine learning algorithms include deep learning neural networks, variational autoencoders, overcomplete autoencoders, support vector machines, random forests, DBScan, KMeans, and other clustering algorithms, as well as Local Outlier Factor.

[0164] According to an embodiment, AI and machine learning can identify an increase in data usage on a metered network and warn the user of significant changes, identify when the user may be in an area with Wi-Fi coverage but not using it, notify the user when, for example, they are in an area with Wi-Fi coverage, and / or address costs by offloading and roaming to Wi-Fi when available. Further, cohort analysis can be used to identify entities that use more / less than others, e.g., entities that conduct more / less transactions than others, entities that use more / less data than others, entities that utilize an expensive pay-per-use network instead of free Wi-Fi, and / or entities that utilize an alternative service.

[0165] AI and machine learning can improve performance and productivity. To address the problem of overuse of "recreational" applications, the methods and systems can be configured to notify, warn, automatically block, suppress, and / or limit usage, and to address the problem of underuse of mission-critical applications. AI and machine learning can notify and warn a VPN server pool, which can issue alerts and log data to a productivity dashboard. Further, the methods and systems can be configured to notify, warn, automatically block, suppress, and / or limit usage as performance and productivity change over time, and to reduce network latency by blocking unwanted traffic such as adware and ads. AI and machine learning can also use cohort analysis to identify devices and users with low performance, e.g., specific users with fewer transactions (productive capacity) than others, devices with failing batteries, devices with abnormal applications, devices using unusual services, and / or unusual or changing time patterns. Further, AI and machine learning can identify areas with historically poor network performance, switch to a better network if available, or alert if a better one is not available. To address cohort analysis for identifying devices and users with low performance, AI and machine learning can identify specific users with fewer transactions (productive capacity) than others, devices with failing batteries, devices with abnormal applications, devices using unusual services, and / or unusual or changing time patterns.

[0166] Regarding security, AI and machine learning can provide threat analysis to help businesses sift through vast amounts of data to find potentially malicious activities by finding only the "interesting information." In this regard, AI and machine learning can monitor and learn the "normal" behavior of a given entity (user, device, application) to identify behavior changes, monitor cohorts to identify different entities, for example, placing a device that becomes infected and starts exhibiting strange behavior under heightened surveillance, detecting entities that upload or download data to an unusual service (such as DropBox), detecting different IP addresses, servers, services, locations or countries, enabled / disabled security software (such as firewalls, DLP, AV, etc.), valid / invalid certificates, key applications that are not present or present on a device, enabled / disabled device security controls, and / or entities that send / receive attempts to access blocked sites with a certain frequency. AI and machine learning can also determine the boundaries of the "normal" location of an individual device and / or device cohort and detect when a device is outside its normal area.

[0167] Based on the findings and / or detections of AI and machine learning, the method and system can block or permit traffic, switch between different network interfaces, use multiple network interfaces, use or not use a proxy server, switch between different proxy servers, enforce encryption between two devices, enforce compression between two devices, enforce the transfer of error detection between two devices, launch an application on a device, execute Diagnostics on a device, enforce strong authentication, enable high-level logging, suppress network usage, limit network destinations, isolate a device, and / or force traffic through an encrypted tunnel.

[0168] Returning to FIG. 5, all attempted network flows 511-513 are captured at the client or client device 510 and routed directly to their intended destinations 513 via a local proxy to a public network or a private network, or proxied via tunnel 511 and routed to their intended destinations 512 via a VPN server pool, or blocked, depending on the currently configured policy of the client. All network flow metadata 514 from the client 510 is sent to a VPN server pool 531 that processes and formats the metadata stream and sends the results as network flow metadata 515 to a reporting engine 535 and a data ingestion server 536. The data ingestion server 536 further processes the results and prepares them for analysis and storage by sending network flow metadata 517 to a data storage 533. The analytics server 534 periodically retrieves and processes network flow metadata 518 from the data storage 533 according to the specific needs of the algorithms, including the machine learning algorithms being used, and generates zero or more alerts. The alerts 540 are sent to the VPN server pool 531, which forwards them to the reporting engine 535 and updates the configured policy 542 on one or more clients or client devices 510 depending on how the user has configured the VPN.

[0169] In view of the above, it is understood that all network flows can be captured such that metadata or information about them can be collected and then all network flows can be written back to the local network stack.

[0170] Embodiments are directed to a method and system for capturing all network flows to and from a computer, recording information about all such flows, and sending all the information to a common data storage. The present invention further includes aggregating the collected data flows in real time and processing the aggregation results via one or more machine learning (ML) algorithms. The method and system group and aggregate previous data flows, add statistical metadata to generate a specialized data set, train a customized ML algorithm using the specialized data set, and further include a specific ML workflow for saving the trained ML model for each group of aggregated flows. As described herein, the machine learning workflow can be interpreted to refer to all the processing required to complete a particular task. The method and system further include grouping and aggregating new data flows into the same specialized data set and generating an anomaly score for the new data by processing the data set via the previously saved ML model for a given group. The method and system are further configured to enable generating an anomaly event by comparing the anomaly score to a threshold and customizing the threshold used to generate the anomaly event and the grouping of the data flows.

[0171] FIG. 39 is an exemplary flowchart 3900 of the network flow information processing of the ML workflow described above. FIG. 39 starts from the processing of previous flow data 3910 used for training. The previous data 3910 is retrieved from the data storage in the server, grouped as separate data flows 3914 (3912), and then processed into a specialized data set 3918 (3916). Using the specialized data set 3918, an ML model can be trained (3920) to generate a trained ML model 3922. Real-time data 3930 received after the ML model is trained (3920) is passed through the trained ML model at 3932 instead of being used to train the ML model, and is processed in the same way as the previous data 3910, except that the trained ML model generates an anomaly score 3934. Each anomaly score is compared with a threshold value (3936), and if the anomaly score is greater than the threshold value, the data during that time is flagged as an anomaly (3938), and an alert is sent to the VPN server pool.

[0172] FIG. 40 is an exemplary flow diagram 4000 showing how network flow information or metadata from a group of devices 4010, namely, the date and time of the flow group, the name of the associated client application, the destination IP address, the destination port, the number of individual flows within the group, the total number of bytes received ("rx"), and the total number of bytes transmitted ("tx"), are processed into a specialized data set. The group of flow data is aggregated into a 15-minute window (4020), and then the number of unique values for the associated application, destination IP address, destination port, and sub-fields of the address ("IP octets") are determined, and the sums for the number of flows, received bytes ("rx"), and transmitted bytes ("tx") are calculated (4030). On the other hand, for the associated application, destination IP address, destination port, and sub-fields of the address ("IP octets") 4040, the total number of unique values across all flows is determined, and at 4050, it is used to calculate the ratio of unique values for each flow group of the associated application, destination IP address, destination port, and sub-fields of the address ("IP octets"). The sums of the number of flows, received bytes ("rx"), and transmitted bytes ("tx") from 4030 are used at 4050 to calculate the ratio of received bytes to the number of flows, the ratio of transmitted bytes to the number of flows, and the ratio of transmitted bytes to received bytes. Also, at 4050, the total number of unique values from 4040 is combined with the unique values of the flow group from 4030 to calculate the entropy of the number of unique values for the flow group. The calculated statistics (4050) are added to the aggregated flow data 4030 to form a specialized data set 4060.

[0173] FIG. 41 is an exemplary diagram 4100 showing an exemplary ML algorithm according to an embodiment that includes a series of neural network layers that together form an overcomplete autoencoder. As input, the ML algorithm takes in a specialized dataset 4060, the 33 values of which (the “features”) are normalized and used as input to a neural network whose output is 80 values. These 80 values are passed to a second neural network (or “layer”) whose output is 106 values. These are passed to an intermediate neural network that acts as a bridge between the “encoding” and “decoding” halves of the ML algorithm, and 160 values are output. The intermediate neural network passes those 160 values to the next layer, which outputs 106 values. The next neural network receives the 106 values and generates 80 values. Those 80 values are passed to a single final neural network that outputs 33 values. In this way, the overcomplete autoencoder attempts to reproduce the input at the output. The 160 values of the intermediate layer can be interpreted as a mathematical representation of the original 33 input values (referred to as the “encoding” of the original input). The process of attempting to reproduce the input at the output is performed by the remaining layers (referred to as “decoding” the output of the intermediate layer). Given this architecture, training can be done using standard gradient descent by taking the difference between the original 33 input values and the 33 values generated at the output.

[0174] The method and system further include a specific ML workflow that generates a specialized dataset by processing aggregated network traffic metadata to obtain higher-dimensional input data. The aggregated network data has fields for each of transfer datetime, received bytes, transmitted bytes, number of flows, application name, destination address, and destination port. The application name, destination address, and destination port are treated as non-numeric (categorical) data. Each unique value for all categorical data is treated as a single input (feature) processed by the ML architecture. As described herein, the machine learning architecture can be interpreted to refer to one or more machine learning algorithms combined to achieve a specific task. As a non-limiting example, if "Explorer" is the application name within the aggregated network traffic, all entries within the specialized dataset include a value called "Explorer", which is the number of times the aggregated network traffic included "Explorer" as the application name within a 15-minute interval. Thus, the specialized dataset includes a set of all unique categorical values within the aggregated network data with the numerical values of received bytes, transmitted bytes, and number of flows added. Thus, a given entry within the specialized dataset is the number of each unique value found within the aggregated network data over a 15-minute interval and the numerical average of received bytes, transmitted bytes, and number of flows reported within the aggregated network data over the same 15-minute interval. Thus, the number of values within all entries of a given specialized dataset is the number of unique application names + the number of unique destination addresses + the number of unique destination ports + 3 (average of received bytes, average of transmitted bytes, and average of number of flows).

[0175] After processing the specialized dataset, subsequent processing is limited to a single computer or a customized group of computers having at least 40 values (features) and data for at least 10 days (about 1000 data points when grouped in 15-minute intervals) from the specialized dataset.

[0176] The present invention uses a two-stage ML architecture. In the first stage, a specialized dataset is used as input to apply a Variational Autoencoder (VAE) ML algorithm. The VAE attempts to reproduce the input entry in its output and calculates the difference between the two to output an "average error" for each entry in the specialized dataset. The second stage includes multiple statistical methods that independently process the average error, and each statistical method generates a score indicating how abnormal a given average error is compared to all previous average errors. The "average score" is generated by averaging the scores from the statistical methods. By comparing the average score with a customizable threshold, it is determined whether the original input should be considered an anomaly.

[0177] The second stage of the present invention implements three statistical methods, namely, One-Class Support-Vector Machine (OC-SVM), Isolation Forest (ISF), and Local Outlier Factor (LOF).

[0178] Figure 42 is an exemplary diagram 4200 showing an ML workflow. This takes a dataset (described above) specialized as input 4210 and passes it through a Variational Autoencoder (VAE) 4220 to generate an average error value 4230. This average error value can pass through three different statistical methods, including, for example, One-Class Support-Vector Machine (OC-SVM) 4240, Isolation Forest (ISF) 4241, and Local Outlier Factor (LOF) 4242, each of which generates a score indicating how rare a given average error value is 1 , score 2 , score 3Generate it. Then, the three scores can be averaged to generate an average score of 4250, which can be compared with a threshold value of 4260. If it exceeds the threshold value of 4260, it is processed or labeled as an anomaly 4270.

[0179] Figure 43 is an exemplary diagram 4300 showing an ML algorithm, which can be a variational autoencoder (VAE) used in the ML workflow shown in Figure 42. The ML algorithm can include five neural network layers that decrease from the number of fields in a specialized dataset to 4 and symmetrically increase back to the input size. In the central layer, four outputs are sampled to two values to form a distribution, which is then used for anomaly detection.

[0180] Figure 44 is an exemplary diagram 4400 showing an idealized variational autoencoder as shown in Figure 43.

[0181] As described above, aspects of embodiments of the present disclosure can be implemented by a dedicated hardware-based system that performs a specified function or operation, or by a combination of dedicated hardware and computer instructions and / or software. In an embodiment, software elements can include firmware, resident software, microcode, and the like.

[0182] As will be understood by those skilled in the art, aspects of the present disclosure may be embodied as a system, method, or computer program product. Accordingly, aspects of embodiments of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining all software and hardware aspects generally referred to herein as a "circuit," "module," or "system." Furthermore, aspects of the present disclosure (e.g., VPN service, reporting engine, analytics server, VPN policy engine) may take the form of a computer program product embodied in a tangible medium having computer-usable program code embodied in the medium.

[0183] Any combination of one or more computer-usable media or computer-readable media can be utilized in servers and clients. The computer-usable media or computer-readable media can be, for example, but not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, devices, or propagation media. More specific examples (a non-exhaustive list) of computer-readable media include electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disc read-only memory (CDROM), optical storage devices, transmission media such as those supporting the Internet or an intranet, magnetic storage devices, USB keys, and / or cellular telephones.

[0184] In the context of this specification, a computer-usable medium or computer-readable medium can be a medium that can store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The computer-usable medium can include a propagated data signal in which computer-usable program code is embodied, either in baseband or as part of a carrier wave. The computer-usable program code can be transmitted using any appropriate medium including, but not limited to, wireless, wireline, fiber optic cable, RF, etc.

[0185] The computer program code for carrying out operations of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, Smalltalk, C++, and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on a client or client device, and partly on a server, whether on-premises or in the cloud. The client or client device can be connected to a VPN server and / or a destination server or service via any type of network, which can include, for example, a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (e.g., via the Internet using an Internet service provider). Additionally, in embodiments, the present invention can be embodied in a field programmable gate array (FPGA).

[0186] FIG. 45 is an exemplary diagram of a system 4000 for use as a client and / or as a VPN server according to the embodiments described herein. System 4500 is shown generally and can include a generally shown computer system 4502 connectable to a network 4522. Computer system 4502 may operate as a stand-alone device or may be connected to other systems or peripherals. With respect to the VPN server, computer system 4502 may include or be included in one or more computers, servers, systems, communication networks, or cloud environments.

[0187] Computer system 4502 may be incorporated into one or both of a server and a client. Computer system 4502 or a portion thereof may be implemented as or incorporated into various devices such as a personal computer, tablet computer, set-top box, personal digital assistant, mobile device, palmtop computer, laptop computer, desktop computer, communication device, wireless phone, personal trusted device, web appliance, or other machine capable of executing a set (sequential or otherwise) of instructions specifying actions taken by that device. Further, while a single computer system 4502 is shown, additional embodiments may include a collection of systems or subsystems that individually or jointly execute instructions or perform functions.

[0188] As shown in FIG. 45, computer system 4502 may include at least one processor 4504, such as, for example, a central processing unit, a graphics processing unit, or both. Computer system 4502 may also include a computer memory 4506. Computer memory 4506 may include static memory, dynamic memory, or both. Computer memory 4506 may additionally or alternatively include a hard disk, random access memory, cache, or combinations thereof. Of course, those skilled in the art will appreciate that computer memory 4506 may comprise any combination of known memories or a single storage.

[0189] As shown in FIG. 45, computer system 4502 may include a computer display 4508, such as, for example, a liquid crystal display device, an organic light emitting diode, a flat panel display, a solid state display, a cathode ray tube, a plasma display device, or other known display. Computer system 4502 may include at least one computer input device 4510, such as a keyboard, a remote control device having a wireless keypad, a microphone coupled to a speech recognition engine, a camera such as a video camera or a still camera, a cursor control device, or any combination thereof. Those skilled in the art will appreciate that various embodiments of computer system 4502 may include multiple input devices 4510. Further, those skilled in the art will appreciate that the exemplary input devices 4510 listed above are not meant to be exhaustive, and that computer system 4502 may include any additional or alternative input devices 4510.

[0190] The computer system 4502 may also include a media reader 4512 and a network interface 4514. Further, the computer system 4502 may include additional devices, components, parts, peripherals, hardware, software, or any combination thereof, which, without limitation, are generally known and understood to be included with or within a computer system, such as an output device 4516. The output device 4516 may be, without limitation, a speaker, audio out, video out, remote control output, or any combination thereof. As shown in FIG. 45, a bus 4518 can be provided for communication between the various components of the computer system 4502.

[0191] Furthermore, aspects of the present disclosure can take the form of a computer program product accessible from a computer useable medium or a computer readable medium providing program code for use by or in connection with a computer or any instruction execution system. The software and / or computer program product can be implemented in the environment of FIG. 45. For the purposes of this description, a computer useable medium or a computer readable medium can be an apparatus that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of computer readable storage media include semiconductor or solid state memory, magnetic tape, removable computer diskette, random access memory (RAM), read only memory (ROM), rigid magnetic disk, and optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read / write (CD-R / W), and DVD.

[0192] This specification describes components and functions that can be implemented in certain embodiments with reference to specific standards and protocols, but the present disclosure is not limited to such standards and protocols. Such standards are regularly replaced by faster or more efficient equivalents having essentially the same functionality. Accordingly, alternative standards and protocols having the same or similar functionality are considered to be their equivalents.

[0193] The exemplification of the embodiments described herein is intended to provide a general understanding of the various embodiments and is not intended to serve as a complete description of all the elements and features of the apparatus and system utilizing the structures or methods described herein. Those skilled in the art, upon considering the present disclosure, may envision many other embodiments. Other embodiments may be utilized and derived from the present disclosure such that structural and logical substitutions and changes may be made without departing from the scope of the present disclosure. Further, the drawings are merely representative and may not be drawn to scale. Specific ratios within the drawings may be exaggerated and other ratios minimized. Accordingly, the present disclosure and the drawings should be regarded as illustrative rather than limiting.

[0194] Accordingly, the present disclosure provides various systems, structures, methods, and apparatuses. Although the present disclosure has been described with reference to some exemplary embodiments, it is understood that the terms used are for purposes of description and exemplification rather than limitation. Changes can be made within the scope and spirit of the present disclosure and within the appended claims as presently stated and as amended. Although the present disclosure has been described with reference to specific materials and embodiments, the embodiments of the present invention are not intended to be limited to the specific ones disclosed, but rather the present invention extends to all functionally equivalent structures, methods, and uses such as those within the scope of the appended claims.

[0195] A computer-readable medium may be described as a single medium, but the term "computer-readable medium" includes a single medium or multiple media, such as a centralized or distributed database, and / or associated caches and servers that store one or more instruction sets. The term "computer-readable medium" also includes any medium that can store, encode, or carry a set of instructions for execution by a processor, or cause a computer system to perform one or more of the embodiments disclosed herein.

[0196] A computer-readable medium may include one or more non-transitory computer-readable media and / or one or more transitory computer-readable media. In certain non-limiting, exemplary embodiments, a computer-readable medium can include solid-state memory such as a memory card, or other packages that house one or more non-volatile read-only memories. Additionally, a computer-readable medium can be random access memory or other volatile rewritable memory. Further, a computer-readable medium can include magneto-optical or optical media such as disks, tapes, or other storage devices for capturing carrier signals such as signals communicated via a transmission medium. Accordingly, the present disclosure is considered to include computer-readable media or other equivalents and successor media on which data or instructions can be stored.

[0197] This specification describes particular embodiments of the present disclosure, but those skilled in the art can devise variations of the present disclosure without departing from the concepts of the invention.

[0198] One or more embodiments of the present disclosure may be referred to individually and / or collectively herein by the term "invention" simply for convenience and without any intention of voluntarily limiting the scope of the application to any particular invention or inventive concept. Further, while particular embodiments are illustrated and described herein, it should be understood that subsequent configurations designed to achieve the same or similar purposes may replace the particular embodiments shown. The present disclosure is intended to cover any and all subsequent adaptations or variations of various embodiments. Combinations of the above-described embodiments and other embodiments not specifically described herein will be apparent to those skilled in the art upon review of the description.

[0199] The subject matter disclosed above should be considered illustrative and not restrictive, and the appended claims are intended to cover all such variations, enhancements, and other embodiments that fall within the true spirit and scope of the present disclosure. Accordingly, the scope of the present disclosure should be determined by the broadest permissible interpretation of the following claims and their equivalents to the fullest extent permitted by law, and should not be limited or restricted by the foregoing detailed description.

[0200] Accordingly, the novel architecture is intended to cover all such changes, modifications, and variations that fall within the spirit and scope of the appended claims. Further, to the extent that the term "comprising" is used in either the detailed description or the claims, such term is intended to be construed as inclusive in the same manner as the term "including" is construed when employed as a transitional term in the claims.

[0201] While the present disclosure has been described with reference to specific embodiments, those skilled in the art will understand that various changes can be made and elements can be replaced with equivalents without departing from the true spirit and scope of the present disclosure. Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of the embodiments of the present disclosure. Rather, the terms used herein are terms for explanation rather than limitation, and it is understood that various changes can be made without departing from the spirit and scope of the present disclosure. In addition, modifications can be made without departing from the essential teachings of the present disclosure. Furthermore, the features of various implementation embodiments can be combined to form further embodiments of the present disclosure.

[0202] This specification describes specific embodiments of the present disclosure, but those skilled in the art can devise variations of the present disclosure without departing from the concepts of the present invention.

[0203] Unless the above description and the accompanying drawings disclose additional subject matter not within the scope of the following claims, the embodiments are not dedicated to the public, and the right to file one or more applications to claim such additional embodiments is reserved.

Claims

A mobile management method executed by a management system, wherein the management system receives a DNS query for a host name from an application on a client, obtains reputation data associated with the host name from a local cache on the client, determines whether there is a policy associated with the host name and the reputation data associated with the host name, based on the policy determined for the host name, sends a network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or blocks the network flow, sends at least network flow metadata to a collector on the client, and sends the network flow metadata in the collector via the VPN tunnel to a VPN server pool, where regardless of whether the network flow is sent via the VPN tunnel, sent from the local proxy, or blocked, the management system sends the network flow metadata to the VPN server pool, the VPN server pool includes a data gateway that receives the network flow metadata, a data publisher coupled to the data gateway instructs a reporting engine to generate at least one of a report or dashboard that instructs the data publisher, and instructs a machine learning unit to discover anomalies, determine cohorts, estimate trends, determine location boundaries, detect network security issues, detect devices at risk, and / or optimize network usage to perform at least one of a mobile management method.

2. The machine learning unit sends an alert to the VPN server pool based on the discovered anomalies, determined cohorts, estimated trends, determined location boundaries, detected network security issues, detected devices at risk, and optimized network usage, and the VPN server pool sends an alert to the client or sends an update to the client. The method according to claim 1.

3. The machine learning unit includes a data storage server that collects and stores network flow metadata from the VPN server pool, and an analysis server. The method includes: In the analysis server, using a statistical algorithm to aggregate the collected metadata stored in the data storage server. Processing the aggregated information by a machine learning algorithm to automatically detect at least one of abnormal data transfer and use for the user of the client. The method according to claim 1, further comprising the above.

4. A mobile management method executed by a management system, wherein the management system Receives a DNS query for a host name from an application on a client. Obtains reputation data associated with the host name from a local cache on the client. Determines whether there is a policy associated with the host name and the reputation data associated with the host name. Based on the policy determined for the host name, Transmits a network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or Blocks the network flow. Transmits at least network flow metadata to a collector on the client, and Transmits the network flow metadata in the collector to a VPN server pool via the VPN tunnel, where The VPN server pool includes machine learning that uses artificial intelligence and machine learning to determine the boundaries of the normal locations of at least one of individual client devices and device cohorts, and to detect when an individual device or device cohort is outside the normal location. Mobile management method.

5. A mobile management method executed by a management system, wherein the management system Receives a DNS query for a host name from an application on a client. Obtains reputation data associated with the host name from a local cache on the client. Determines whether there is a policy associated with the host name and the reputation data associated with the host name. Based on the policy determined for the host name, send the network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or block the network flow, send at least network flow metadata to a collector on the client, and send the network flow metadata in the collector via the VPN tunnel to a VPN server pool, where the VPN server pool includes a machine learning unit that uses artificial intelligence and machine learning to perform discovery and detection based on at least network flow metadata, the method is such that based on the discovery and detection by the artificial intelligence and machine learning, the management system permits or blocks traffic, switches the use of different network interfaces, uses multiple network interfaces, uses or does not use a proxy server, switches between different proxy servers, forces compression between two devices, forms forward error detection between two devices, starts an application on a device, executes a diagnosis on a device, forces enhanced authentication, enables enhanced logging, suppresses network usage, limits network destinations, isolates the device, and forces traffic to pass through an encrypted tunnel including further performing at least one of the above, mobile management method.

6. Updating the reputation data regarding the host name is such that the management system sends a request via the VPN tunnel to search for reputation data regarding the host name from the server, and receives the searched reputation data regarding the host name from the server via the VPN tunnel The method according to claim 4, including performing.

7. A mobile management method executed by a management system, wherein the management system receives a DNS query for a host name from an application on a client, Obtain reputation data associated with the host name from the local cache on the client, Determine whether there is a policy associated with the host name and the reputation data associated with the host name, Based on the policy determined for the host name, Transmit the network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or Block the network flow, where If the DNS query for the host name cannot be resolved based on a policy in the client, the method is that the management system Transmits the DNS query via the VPN tunnel to a VPN server pool, Receives the resolved host name via the VPN tunnel and transfers the resolved host name to the application, Receives a request to transfer a network flow to a remote host of the resolved host name, Obtain reputation data associated with the remote host from the local cache on the client, Determine whether there is a policy associated with the remote host and the reputation data associated with the remote host, Based on the determined policy for the remote host Transmit the network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or Block the network flow further includes a mobile management method.

8. A mobile management method executed by a management system, wherein the management system Receives a DNS query for a host name from an application on a client, Obtain reputation data associated with the host name from the local cache on the client, Determine whether there is a policy associated with the host name and the reputation data associated with the host name, Based on the policy determined for the host name, Transmit the network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or Block the network flow, where if the DNS query for the host name cannot be resolved based on a policy in the client, the method includes the management system sending the DNS query to the local network receiving the resolved host name via the local network and transferring the resolved host name to the application receiving a request to transfer a network flow to a remote host of the resolved host name obtaining reputation data associated with the remote host from a local cache on the client determining whether there is a policy associated with the remote host and the reputation data associated with the remote host based on the determined policy of the remote host sending the network flow to a server via a VPN tunnel or from a local proxy on the client to a private or public network, or blocking the network flow The mobile management method further includes. Claim 9 The client is a mobile client that roams between a plurality of different networks, the DNS query is processed while the VPN tunnel is established on a first network, and the network flow to the remote host is transmitted via the VPN tunnel while the VPN tunnel is established on a second network different from the first network. The method according to claim 7.

Images