Application Access Analyzer

Abstract

Techniques for application access analyzers are disclosed. In some embodiments, a system / process / computer program product for an application access analyzer includes monitoring access to an application across a network, using the application access analyzer to automatically determine the root cause of problems (e.g., network connectivity anomalies, performance degradation, and / or permission denial and / or policy blocking) related to a user's (e.g., or a group of users') access to an application across a network, and taking action in response to determining the root cause of problems related to access to an application across a network.

Description

Technical Field

[0001] Cross - reference to related applications This application claims priority to U.S. Provisional Patent Application No. 63 / 459,494, titled "APPLICATION ACCESS ANALYZER", filed on April 14, 2023; U.S. Provisional Patent Application No. 63 / 459,492, titled "SECURITY POLICY ANALYSIS - DEVOPS APPROACH", filed on April 14, 2023; and U.S. Provisional Patent Application No. 63 / 459,500, titled "TOPOLOGICAL CO - RELATION", filed on April 14, 2023, all of which are incorporated herein by reference for all purposes.

Background Art

[0002] Malware is a common term generally used to refer to malicious software (e.g., including various hostile, invasive, and / or otherwise unwanted software). Malware can be in the form of code, scripts, active content, and / or other software. Examples of the use of malware include disrupting the operation of a computer and / or computer network, stealing confidential information (e.g., confidential information such as identity, financial, and / or intellectual property - related information), and / or obtaining access to a private / dedicated computer system and / or computer network. Unfortunately, as techniques are developed to detect and help mitigate malware, malicious creators find ways to avoid such efforts. Thus, there is a continuing need for improvements to techniques for identifying and mitigating malware.

Brief Description of the Drawings

[0003] Various embodiments of the present invention are disclosed in the following detailed description and accompanying drawings. [Figure 1] Figure 1 shows an exemplary environment in which a malicious application ("malware") is detected and prevented from causing harm. [Figure 2A] Figure 2A shows an embodiment of the data appliance. [Figure 2B] Figure 2B is a functional diagram of the logical components according to an embodiment of the data appliance. [Figure 3] Figure 3 shows an exemplary logical component that may be included in a system for analyzing a sample. [Figure 4] Figure 4 shows one exemplary Secure Access Service Edge (SASE) and network environment illustrating the technical challenges for application access visibility according to several embodiments. [Figure 5A] Figure 5A shows one exemplary interface for an Application Access Analyzer (AAA) according to several embodiments. [Figure 5B] Figure 5B shows one exemplary interface for an Application Access Analyzer (AAA) according to several embodiments. [Figure 6A] Figure 6A shows a service architecture for AAA according to several embodiments. [Figure 6B] Figure 6B is a table summarizing the data sources used in an exemplary problem, which are analyzed using the AAA service according to several embodiments. [Figure 6B-1] Figure 6B is a table summarizing the data sources used in an exemplary problem, which are analyzed using the AAA service according to several embodiments. [Figure 6C]Figure 6C is a sequence diagram of an App Connectivity Analyzer using AAA services according to several embodiments. [Figure 7] Figure 7 shows AAA in operation according to several embodiments. [Figure 8] Figure 8 shows one exemplary implementation of AAA that incorporates domain knowledge in the form of a playbook and performs playbook analysis through the execution of a Directed Acyclic Graph (DAG), according to several embodiments. [Figure 9] Figure 9 is a flowchart illustrating the process for AAA service according to several embodiments. [Figure 10] Figure 10 is another flowchart relating to the process for AAA service according to several embodiments. [Figure 11] Figure 11 is another flowchart relating to the process for AAA service according to several embodiments. [Figure 11-1] Figure 11 is another flowchart relating to the process for AAA service according to several embodiments. [Modes for carrying out the invention]

[0004] The present invention can be implemented in numerous ways, including processes, apparatus, systems, compositions, computer program products embodied on computer-readable storage media, and / or instructions stored in memory, and / or processors configured to execute instructions stored and / or provided by memory coupled to the processor. In this specification, these implementations, or any other forms the present invention may take, may be referred to as techniques. Generally, the order of the steps of the disclosed process may be modified within the scope of the invention. Unless otherwise specified, components such as processors or memory described as configured to perform a task may be implemented as general-purpose components temporarily configured to perform a task at a given time, or as specific components manufactured to perform a task. As used herein, the term “processor” refers to one or more devices, circuits, and / or processing cores configured to process data, such as computer program instructions.

[0005] A detailed description of one or more embodiments of the present invention, along with accompanying drawings illustrating the principles of the present invention, is provided below. While the present invention is described in relation to such embodiments, it is not limited to any embodiment. The scope of the present invention is limited solely by the claims, and the present invention encompasses numerous alternatives, modifications, and equivalents. Numerous specific details are provided below to provide a complete understanding of the present invention. These details are provided for illustrative purposes only, and the present invention may be carried out in accordance with the claims without some or all of these specific details. For clarity, technical materials known in the art related to the present invention are not described in detail so as not to unnecessarily obscure the present invention.

[0006] A firewall generally allows authorized communications to pass through while protecting the network from unauthorized access. Typically, a firewall is a device, a set of devices, or software running on a device that provides firewall functionality for network access. For example, a firewall can be integrated into the operating system of a device (e.g., a computer, smartphone, or other type of network-enabled device). Firewalls can also be integrated or run as software applications on various types of devices or security devices, such as computer servers, gateways, network / routing devices (e.g., network routers), or data appliances (e.g., security equipment or other types of special-purpose devices), and in some implementations, specific operations can be implemented on special-purpose hardware such as ASICs or FPGAs. ru.

[0007] Firewalls typically deny or allow network transmissions based on a set of rules. These sets of rules are often referred to as policies (e.g., network policies or network security policies). For example, a firewall can filter inbound traffic by applying a set of rules or policies to prevent unwanted external traffic from reaching the protected device. Firewalls can also filter outbound traffic by applying a set of rules or policies (e.g., allow, block, monitor, notify, log, and / or other actions that may be specified in firewall rules or firewall policies, which can be triggered based on various criteria, as described here). Firewalls can also filter local network (e.g., intranet) traffic by similarly applying a set of rules or policies.

[0008] Security devices (e.g., security equipment, security gateways, security services, and / or other security devices) can perform a variety of security operations (e.g., firewalls, anti-malware, intrusion prevention / detection, proxies, and / or other security functions), network functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other network functions), and / or other security and / or network-related functions. For example, routing can be performed based on source information (e.g., IP address and port), destination information (e.g., IP address and port), and protocol information.

[0009] A basic packet filtering firewall filters network communication traffic by inspecting individual packets transmitted over the network (e.g., a stateless packet filtering firewall, a packet filtering firewall, or a first-generation firewall). A stateless packet filtering firewall typically inspects the individual packets themselves and then applies rules based on the inspected packets (e.g., using a combination of source and destination address information, protocol information, and port number).

[0010] An application firewall can also perform application layer filtering (for example, using an application layer filtering firewall or a second-generation firewall that operates at the application level of the TCP / IP stack). An application layer filtering firewall or application firewall can generally identify a given application and protocol (e.g., web browsing using Hypertext Transfer Protocol (HTTP), Domain Name System (DNS) requests, file transfers using File Transfer Protocol (FTP), and various other types of applications and protocols such as Telnet, DHCP, TCP, UDP, and TFTP (GSS)). For example, an application firewall can block unauthorized protocols attempting to communicate on standard ports (for example, unauthorized / unauthorized policy protocols attempting to sneak through by using non-standard ports for that protocol can generally be identified using an application firewall).

[0011] A stateful firewall can also perform stateful-based packet inspection, where each packet is examined within the context of its network transmission packet flow and the set of packets associated with it. This firewall technique is commonly referred to as stateful packet inspection because it maintains a record of all connections passing through the firewall and can determine whether a packet is the start of a new connection, part of an existing connection, or an invalid packet. For example, the state of a connection can itself be one of the criteria that trigger rules in a policy.

[0012] Advanced or next-generation firewalls, as described above, can perform stateless and stateful packet filtering and application layer filtering. Next-generation firewalls can also perform additional firewall technologies. For example, a given new firewall, often referred to as an advanced or next-generation firewall, can also identify users and content. In particular, a given next-generation firewall extends the list of applications that these firewalls can automatically identify to thousands of applications. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (e.g., Palo Alto Networks' PA series firewalls). For example, Palo Alto Networks' next-generation firewalls use various identification technologies to enable enterprises and service providers to identify and control applications, users, and content—not just ports, IP addresses, and packets. Various identification technologies include Application ID (App-ID) for precise application identification, User ID (User-ID) for user identification (e.g., a user or user group), and Content ID (Content-ID) for real-time content scanning (e.g., controlling web surfing and restricting data and file transfers). These identification technologies allow businesses to securely enable application usage using business-relevant concepts, instead of following the traditional approach provided by conventional port-blocking firewalls.Furthermore, purpose-specific hardware for next-generation firewalls (for example, implemented as dedicated devices) generally provides a higher level of performance for application inspection than software running on general-purpose hardware (for example, security devices offered by Palo Alto Networks, which utilize dedicated, function-specific processing tightly integrated with a single-path software engine to minimize latency while maximizing network throughput for Palo Alto Networks' PA series next-generation firewalls).

[0013] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of such next-generation firewalls are commercially available from Palo Alto Networks (Palo Alto Networks firewalls are compatible with VMware(R) ESXi). TM and NSX TM Citrix(R) Netscaler SDX TM It supports a variety of commercial virtualization environments, including KVM / OpenStack (CentOS / RHEL, Ubuntu(R)), Amazon Web Services (AWS), and the CN series container next-generation firewall. For example, the virtualization firewall can support similar or completely identical next-generation firewalls and advanced threat prevention features available in physical form factor devices, enabling enterprises to securely allow applications to flow into private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and REST-based APIs allow enterprises to dynamically monitor VM changes and reflect that context in security policies, thereby eliminating policy lag that may occur when VMs change.

[0014] Overview of Techniques for Application Access Analyzers

[0015] Generally, existing information technology (IT) operations must pass through thousands to millions of logs and numerous devices in the enterprise infrastructure to identify application connectivity issues for a user or group of users. Troubleshooting and debugging connectivity issues typically require expertise in domain knowledge such as network architecture, routing / switching, server configuration, understanding complex network security policies, and knowledge of vendor-specific operating systems (OS) and command-line interfaces (CLI). Thus, this significantly increases the human time and average time required to detect and resolve application connectivity issues.

[0016] Specifically, identifying software as a service (SaaS) / private application connectivity issues as a service in large-scale network infrastructure is technically difficult due to the vast area of the domain that generally requires thorough checking and analysis. This leads to a significant increase in the average time required to detect and fix issues in SaaS / private application (App) connectivity issues, especially in large-scale network infrastructure. Thus, many secure access service edge (SASE) providers and enterprise organizations are attempting to solve this problem through different methods using artificial intelligence (AI) and / or machine learning (ML) technologies. Automating the detection and repair of application connectivity issues can reduce the mean time to recovery (MTTR) and the operational cost to the organization. Furthermore, providing solutions that facilitate automated detection and repair of application connectivity issues can help SASE providers increase their customer base with high-quality products and customer satisfaction.

[0017] Accordingly, new and improved solutions for facilitating application access analysis are disclosed in relation to various embodiments.

[0018] Specifically, an Application Access Analyzer (AAA) is disclosed that provides an interface (e.g., a natural language (NL) query interface) to operators (e.g., IT / administrators, such as an IT help desk or other technical support personnel / users) to detect application reachability, connectivity, and access / permission issues. The disclosed AAA facilitates auto remediation. As one example, the AAA provides comprehensive details of analyses and checks performed in different categories (separate domains, such as user / endpoint analysis, networking analysis, and security policy analysis, as further described below) to actionable verdicts for queries submitted by operators. Specifically, AAA automatically discovers the network topology used by a given user (e.g., a user specified in a query) to access a given application (e.g., a SaaS / private application specified in a query), analyzes the operational status of the underlying network infrastructure, performs user authentication analysis, checks the health and reachability of the Domain Name System (DNS) and authentication (Auth) servers that the user reaches before accessing the application, and infers user- or user group-specific security policy reasonsing for any access / permission issues.

[0019] Actionable determination, root cause analysis, and pinpointing the problem significantly reduce the average time to resolve application connectivity issues. Actionable determination, root cause analysis, and problem identification also save operators the hassle and time they would otherwise have to perform by following runbooks / playbooks and debugging multiple devices, which typically require domain knowledge and expertise.

[0020] As one example, the disclosed AAA may be used to check connectivity issues between (1) users, users, and / or groups of users to SaaS applications from a mobile user gateway, (2) users, users, and / or groups of users to private applications hosted in an on-premises data center or in a remote branch office, and (3) one or more users, users, and / or groups of users to remote site connectivity to a remote branch or data center.

[0021] In some embodiments, a system / process / computer program product for an Application Access Analyzer (AAA) includes monitoring access to applications across a network, using the Application Access Analyzer to automatically determine the root cause of problems associated with network access to applications for users (e.g., network connectivity anomalies, performance degradation, and / or permission denial and / or policy blocking), and taking action in response to determining the root cause of problems associated with network access to applications for users.

[0022] In one embodiment, the disclosed AAA may be used to determine the root cause of an application access problem by using AI and ML to correlate multiple data sources across multiple domains (e.g., network, authentication, DNS, SaaS / private application health, security policy configuration, etc.), as further described below.

[0023] In one embodiment, the disclosed AAA may be used to automatically detect anomalies and / or performance degradations in network connectivity (e.g., anomalies and / or performance degradations in network connectivity, based on the user's location / access point, based on configurable thresholds for determining reachability and / or performance degradations to a given application for the user), as further described below.

[0024] In one embodiment, the disclosed AAA may be used to generate human-consumable / understandable and actionable decision analysis that significantly reduces the average time to detect and correct application connectivity issues, as further described below.

[0025] In one embodiment, the disclosed AAA may be used to perform a comprehensive analysis of various troubleshooting domains within a short period of time (e.g., a few minutes), which would otherwise typically require a lot of time to troubleshoot each domain, as will be further described below.

[0026] In one embodiment, the disclosed AAA may be used to perform analyses including identifying network infrastructure issues, customer network service issues, client connectivity issues, SaaS / private application (app) health, and reachability issues, as further described below. For example, the disclosed AAA can provide actionable summaries for each troubleshooting domain, and operators do not need to possess domain knowledge expertise to detect and correct the issues.

[0027] In one embodiment, the disclosed AAA can automatically discover (auto-discover) the network topology that will be used by users to access an application, and perform an analysis of potential application access problems.

[0028] In one embodiment, the disclosed AAA may be used to provide a security attitude (posture) assessment by constructing a unified logical model for calculations about the firewall's security policy.

[0029] In one embodiment, the disclosed AAA may be used to manage and maintain network topology issues, networking configuration issues, network services, and security policy tracks, which are often complex and potentially error-prone, as will be further described below. For example, the disclosed AAA can provide a comprehensive analysis of each of these domains using a convenient natural language (NL) query interface.

[0030] In one embodiment, the disclosed AAA can incorporate domain knowledge in the form of a playbook and perform playbook analysis through the execution of a directed acyclic graph (DAG) (for example, implemented as a computed DAG, as further described below).

[0031] In one embodiment, the disclosed AAA may be used to significantly reduce the operational and support costs for an enterprise and its users to access SaaS / private applications.

[0032] In one exemplary implementation, the disclosed AAA is implemented as the Prisma AI Operations (AIOP) platform, designed for use by Network Operations Center (NOC) personnel supporting SASE customers, providing proactive service level management across customers globally, as further described below. Specifically, the Prisma AIOP platform provides proactive monitoring, alerting, problem isolation, and playbook-driven remediation to deliver SLAs (MTTK / I, MTTR) as desired / required by customers.

[0033] Accordingly, new and improved security solutions that facilitate application access analyzers are disclosed according to several embodiments.

[0034] These and other embodiments and examples of the Application Access Analyzer (AAA) are described further below.

[0035] Exemplary System Environment for Application Access Analyzer

[0036] Accordingly, in some embodiments, the disclosed technology includes providing a security platform configured to provide DPI capabilities (including, for example, stateful inspection), as further described below (for example, the security function / platform may be implemented using another (virtual) device / component that can implement security policies using the disclosed technology, such as a firewall (FW) / next-generation firewall (NGFW), a network sensor acting in place of a firewall, or PANOS running on a commercially available virtual / physical NGFW solution from Palo Alto Networks, or another security platform / NFGW, including, for example, Palo Alto Networks' PA Series next-generation firewalls, Palo Alto Networks' VM Series virtualized next-generation firewalls, and CN Series container next-generation firewalls, and / or other commercially available virtual-based or container-based firewalls, which may also be implemented and configured to perform the disclosed technology), for example, it may be provided in part or as a whole as a SASE security solution, where the cloud-based security solution (e.g., SASE) may be monitored using the disclosed technology for an application access analyzer.

[0037] Figure 1 shows an exemplary environment in which a malicious application (malware) is detected and prevented from causing harm. As will be described in more detail below, malware classification (for example, as performed by security platform 122) can be shared and / or refined in various ways among the various entities included in the environment shown in Figure 1. The techniques described herein can then be used to protect devices, such as endpoint client devices 104-110, from such malware.

[0038] As used herein, “malware” refers to an application that engages in behavior that a user would not authorize if fully informed, whether or not it is secret (and illegal). Exemplary examples of malware include ransomware, Trojans, viruses, rootkits, spyware, hacking tools, etc. One example of malware is a desktop / mobile application (e.g., ransomware) that encrypts data stored by a user. Another example of malware is C2 malware, similarly described above. Other forms of malware (e.g., keyloggers) can also be detected / blocked using the disclosed techniques for sample traffic-based self-learning malware detection, as further described herein.

[0039] The techniques described herein can be used with various platforms (e.g., servers, computing appliances, virtual / container environments, desktops, mobile devices, game platforms, embedded systems, etc.) and / or for the automated detection of various forms of malware (e.g., novel and / or variants of malware, such as C2 malware). In the exemplary environment shown in Figure 1, client devices 104-108 are a laptop computer, a desktop computer, and a tablet (each) located within the corporate network 140. Client device 110 is a laptop computer located outside the corporate network 140.

[0040] The data appliance 102 is configured to enforce policies regarding communication between client devices, such as client devices 104 and 106, and nodes outside the corporate network 140 (e.g., reachable via the external network 118). Exemplary such policies include those managing traffic shaping, quality of service, and traffic routing. Other exemplary policies include security policies requiring scanning for threats in incoming (and / or outgoing) email attachments, website content, files exchanged via instant messaging programs, and / or other file transfers. In some embodiments, the data appliance 102 is also configured to enforce policies regarding traffic remaining within the corporate network 140.

[0041] One embodiment of the data appliance is shown in Figure 2A. The example shown is a representation of the physical components included in the data appliance 102 in various embodiments. Specifically, the data appliance 102 includes a high-performance multi-core central processing unit (CPU) 202 and random access memory (RAM) 204. The data appliance 102 also includes storage 210 (such as one or more hard disks or solid-state units). In various embodiments, the data appliance 102 stores information (in either RAM 204, storage 210, and / or other appropriate locations) used to monitor the enterprise network 140 and implement the disclosed technologies. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policy and other configuration information, signatures, hostname / URL classification information, malware profiles, and machine learning (ML) models (e.g., for sample traffic-based self-learning malware detection). The data appliance 102 may also include one or more optional hardware accelerators. For example, the data appliance 102 may include a cryptographic engine 206 configured to perform encryption and decryption operations, and one or more field-programmable gate arrays 208 configured to perform matching, act as a network processor, and / or perform other tasks.

[0042] The functionality described herein as being performed by the data appliance 102 can be provided / implemented in a variety of ways. For example, the data appliance 102 may be a dedicated device or set of devices. The functionality provided by the data appliance 102 may also be integrated or run as software on a general-purpose computer, computer server, gateway, and / or network / routing device. In some embodiments, at least some of the services described herein as being provided by the data appliance 102 are instead (or in addition to) provided to a client device (e.g., client device 104 or client device 110) by software running on the client device.

[0043] Whenever the data appliance 102 is described as performing a task, a single component, a subset of components, or all components of the data appliance 102 may work together to perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, a subcomponent may perform the task, and / or a component may perform the task together with other components. In various embodiments, parts of the data appliance 102 are provided by one or more third parties. Depending on factors such as the amount of computing resources available to the data appliance 102, various logical components and / or features of the data appliance 102 may be omitted, and the techniques described herein will be adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data appliance 102 as applicable. One example of a component included in the data appliance 102 in various embodiments is an application identification engine configured to identify applications (for example, using various application signatures to identify an application based on packet flow analysis). For example, the application identification engine can determine the type of traffic a session is involved in, such as web browsing-social networking, web browsing-news, SSH, etc.

[0044] Figure 2B is a functional diagram of the logical components of one embodiment of the data appliance. The examples shown represent the logical components that may be included in the data appliance 102 in various embodiments. Unless otherwise specified, the various logical components of the data appliance 102 can generally be implemented in various ways, including a set of one or more scripts (e.g., written in Java, Python, etc., where applicable).

[0045] As shown in the diagram, the data appliance 102 includes a firewall and contains a management plane 232 and a data plane 234. The management plane is responsible for managing user interaction by providing a user interface for setting policies and displaying log data. The data plane is responsible for data management by performing packet processing and session processing.

[0046] The network processor 236 is configured to receive packets from client devices, such as client device 108, and provide them to the data plane 234 for processing. Whenever the flow module 238 identifies a packet as part of a new session, it generates a new session flow. Subsequent packets are identified as belonging to the session based on the flow lookup. SSL decryption is applied by the SSL decryption engine 240 where applicable; otherwise, processing by the SSL decryption engine 240 is omitted. The decryption engine 240 helps the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic, and therefore helps stop threats that might otherwise remain hidden within encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaving the corporate network 140. Decryption can be selectively controlled (e.g., enabled or disabled) based on parameters such as URL category, traffic source, traffic destination, user, user group, and port. In addition to the decryption policy (for example, specifying the session to decrypt), a decryption profile can be assigned to control various options for the session controlled by the policy. For example, the use of a specific cipher suite and encryption protocol version may be required.

[0047] The Application Identification (APP-ID) engine 242 is configured to determine the type of traffic a session is involved in. For example, the application identification engine 242 can recognize a GET request in incoming data and conclude that the session requires an HTTP decoder. In some cases, such as a web browsing session, the identified application can change, and such changes are noted by the data appliance 102. For example, a user might first browse a company wiki (classified as "Web Browsing - Productivity" based on the visited URL) and then browse a social networking site (classified as "Web Browsing - Social Networking" based on the visited URL). Different types of protocols have corresponding decoders.

[0048] Based on the decision made by the application identification engine 242, the packet is sent to the appropriate decoder, which is configured by the threat engine 244 to assemble the packet (which may be received out of order) into the correct order, perform tokenization, and extract information. The threat engine 244 also performs signature matching to determine what should happen to the packet. If necessary, the SSL cryptography engine 246 can re-encrypt the decrypted data. The packet is then forwarded using the forwarding module 248 for forwarding (e.g., to the destination).

[0049] Furthermore, as shown in Figure 2B, policy 252 is also received and stored in the management plane 232. A policy may include one or more rules, which can be specified using a domain name and / or host / server name, and the rules may apply one or more signatures or other matching criteria or heuristic methods, such as for security policy enforcement on subscriber / IP flows, based on various extracted parameters / information from the monitored session traffic flow. An exemplary policy may include a C2 malware detection policy that uses disclosed techniques for sample traffic-based self-learning malware detection. An interface (I / F) communicator 250 is provided for management communications (e.g., via (REST) ​​API, messages, or network protocol communications, or other communication mechanisms).

[0050] Security platform

[0051] Returning to Figure 1, suppose a malicious individual (using System 120) has created malware 130 for a malicious web campaign (for example, the malware may be delivered to a user's endpoint device via a compromised website when the user visits / browses the compromised website, or via a phishing attack, etc.). The malicious individual wants a client device, such as client device 104, to run a copy of malware 130, unpack the malware executable / payload, compromise the client device, and, for example, become a bot in a botnet. The compromised client device may then be instructed to perform tasks (for example, cryptocurrency mining or participating in a denial of service attack) and to report information to an external entity, such as a command and control (C2 / C&C) server 150, and, where applicable, to receive instructions from the C2 server 150.

[0052] Assume that data appliance 102 intercepts an email sent (for example, by system 120) to a user "Alice" operating client device 104. In this example, Alice receives the email and clicks a link to a phishing / compromised site that may result in an attempt by Alice's client device 104 to download malware 130. However, in this example, data appliance 102 can perform the disclosed techniques for sample traffic-based self-learning malware detection and block access to the packed malware content from Alice's client device 104, thereby preempting and preventing any such download of malware 130 to Alice's client device 104. As further described below, data appliance 102 performs the disclosed techniques for sample traffic-based self-learning malware detection, as further described below, to detect such malware 130 and block it from harming Alice's client device 104.

[0053] In various embodiments, the data appliance 102 is configured to work in cooperation with the security platform 122. As one example, the security platform 122 may provide the data appliance 102 with a set of signatures for known malicious files (e.g., as part of a subscription). If the signature for malware 130 is included in the set of signatures (e.g., the MD5 hash of malware 130), the data appliance 102 may accordingly prevent the transmission of malware 130 to the client device 104 (e.g., by detecting that the MD5 hash of an email attachment sent to the client device 104 matches the MD5 hash of malware 130). The security platform 122 may also provide the data appliance 102 with a list of known malicious domains and / or IP addresses, enabling the data appliance 102 to block traffic between the corporate network 140 and the C2 server 150 (e.g., if the C2 server 150 is known to be malicious). A list of malicious domains (and / or IP addresses) can also help the data appliance 102 determine when one of its nodes was compromised. For example, if a client device 104 attempts to contact a C&C server 150, such an attempt is a strong indicator that client 104 is compromised by malware (and accordingly, corrective measures should be taken, such as preventing client device 104 from communicating with other nodes in the corporate network 140).

[0054] As will be described in more detail below, the security platform 122 may also receive a copy of the malware 130 from the data appliance 102 to perform cloud-based security analysis to perform sample traffic-based self-learning malware detection, and the malware determination may be sent back to the data appliance 102 to enforce security policies, thereby safeguarding Alice's client device 104 from the execution of the malware 130 (for example, blocking access to the malware 130 on the client device 104).

[0055] In various embodiments, if the signature of an attachment cannot be found, the data appliance 102 may take various actions. As a first example, the data appliance 102 can fail-safe by blocking the transmission of any attachments that are not allowed-listed as benign (e.g., those that do not match the signatures of known good files). The drawback of this approach is that many legitimate attachments, which are actually benign, are unnecessarily blocked as potential malware. As a second example, the data appliance 102 can fail-danger by allowing the transmission of any attachments that are not blocked-listed as malicious (e.g., those that do not match the signatures of known bad files). The drawback of this approach is that newly created malware (that was not previously detected by platform 122) is not prevented from causing harm. As a third example, the data appliance 102 may be configured to provide a file (e.g., malware 130) to the security platform 122 for static / dynamic analysis to determine whether it is malicious and / or, if not, to classify it.

[0056] The security platform 122 stores a copy of the received sample in storage 142, and analysis is initiated (or scheduled, if applicable). One example of storage 142 is an Apache Hadoop Cluster (HDFS). The results of the analysis (and additional information about the application) are stored in database 146. If the application is determined to be malicious, the data appliance may be configured to automatically block file downloads based on the analysis results. Furthermore, a signature for the malware is generated and distributed (to data appliances such as data appliances 102, 136, and 148, for example) to automatically block future file transfer requests for downloading files determined to be malicious.

[0057] In various embodiments, the security platform 122 includes one or more dedicated commercial hardware servers running a typical server-class operating system (e.g., Linux®) (e.g., having a multi-core processor, 32G+ RAM, a Gigabit network interface adapter, and a hard drive). The security platform 122 may be implemented across a scalable infrastructure including multiple such servers, solid-state drives, and / or other applicable high-performance hardware. The security platform 122 may comprise several distributed components, including components provided by one or more third parties. For example, some or all of the security platform 122 may be implemented using Amazon Elastic Compute Cloud (EC2) and / or Amazon Simple Storage Service (S3). Furthermore, as with the data appliance 102, whenever the security platform 122 is referred to as performing a task such as storing or processing data, it should be understood that one or more subcomponents of the security platform 122 may cooperate (individually or in cooperation with third-party components) to perform that task. As one example, the security platform 122 can optionally collaborate with one or more virtual machine (VM) servers, such as VM server 124, to perform static / dynamic analysis.

[0058] One exemplary virtual machine server is a physical machine containing commercially available server-class hardware (e.g., a multi-core processor, 32+ gigabytes of RAM, and one or more gigabit network interface adapters) running commercially available virtualization software. Examples include VMware ESXi, Citrix XenServer, or Microsoft Hyper-V. In some embodiments, the virtual machine server is omitted. Furthermore, the virtual machine server may be under the control of the same entity managing the security platform 122, or it may be provided by a third party. As an example, the virtual machine server may rely on EC2, and the rest of the security platform 122 is provided by dedicated hardware owned and under the control of the operator of the security platform 122. The VM server 124 is configured to provide one or more virtual machines 126-128 to emulate client devices. The virtual machines can run various operating systems and / or versions thereof. Observed behavior resulting from running applications on the virtual machines is logged and analyzed (e.g., for indications that the application is malicious). In some embodiments, log analysis is performed by a VM server (e.g., VM server 124). In other embodiments, the analysis is performed, at least partially, by other components of the security platform 122, such as the coordinator 144.

[0059] In various embodiments, the security platform 122 makes the results of the sample analysis available to the data appliance 102 as part of a subscription, via a list of signatures (and / or other identifiers). For example, the security platform 122 may periodically (e.g., daily, hourly, or at some other interval and / or based on events configured by one or more policies) send content packages that identify malware files, including network traffic-based heuristic IPS malware detection, etc. The subscription may simply cover the analysis of files intercepted by the data appliance 102 and sent to the security platform 122 by the data appliance 102, and may also cover the signatures of malware known to the security platform 122.

[0060] In various embodiments, the security platform 122 is configured to provide security services to various entities in addition to (or, where applicable, instead of) the operators of the data appliance 102. For example, other companies, each having its own corporate networks 114 and 116 and its own data appliances 136 and 148, respectively, can contract with the operator of the security platform 122. Other types of entities can also utilize the services of the security platform 122. For example, an Internet service provider (ISP) providing internet services to a client device 110 can contract with the security platform 122 to analyze applications that the client device 110 attempts to download. As another example, the owner of the client device 110 can install software on the client device 110 that communicates with the security platform 122 (e.g., receiving a content package from the security platform 122, using the received content package to check attachments according to the techniques described herein, and then sending the application to the security platform 122 for analysis).

[0061] Sample analysis using static / dynamic analysis

[0062] Figure 3 shows an exemplary logical component that may be included in a system for analyzing samples. The analysis system 300 can be implemented using a single device. For example, the functionality of the analysis system 300 may be implemented in a malware analysis module 112 integrated into a data appliance 102. The analysis system 300 can also be implemented collectively across multiple separate devices. For example, the functionality of the analysis system 300 may be provided by a security platform 122.

[0063] In various embodiments, the analysis system 300 utilizes a list, database, or other collection (collectively shown as collection 314 in Figure 3) of known secure content and / or known malicious content. Collection 314 can be obtained in various ways, including via a subscription service (e.g., provided by a third party) and / or as a result of other processing (e.g., performed by data appliance 102 and / or security platform 122). Examples of information contained in collection 314 include URLs, domain names, and / or IP addresses of known malicious servers, URLs, domain names, and / or IP addresses of known secure servers, URLs, domain names, and / or IP addresses of known command and control (C2 / C&C) domains, signatures, hashes, and / or other identifiers of known malicious applications, signatures, hashes, and / or other identifiers of known secure applications, signatures, hashes, and / or other identifiers of known malicious files (e.g., OS exploit files), signatures, hashes, and / or other identifiers of known secure libraries, and signatures, hashes, and / or other identifiers of known malicious libraries.

[0064] In various embodiments, when a new sample is received for analysis (for example, when no existing signature associated with the sample exists in the analysis system 300), it is added to the queue 302. As shown in Figure 3, application 130 is received by system 300 and added to the queue 302.

[0065] The coordinator 304 monitors the queue 302 and, when a resource (e.g., a static analysis worker) becomes available, the coordinator 304 fetches a sample from the queue 302 for processing (e.g., fetching a copy of malware 130). In particular, the coordinator first provides the sample to the static analysis engine 306 for static analysis (305). In some embodiments, one or more static analysis engines are included within the analysis system 300, where the analysis system 300 is a single device. In other embodiments, static analysis is performed by a separate static analysis server containing multiple workers (i.e., multiple instances of the static analysis engine 306).

[0066] The static analysis engine obtains general information about the sample and includes it (along with heuristic information and other information, where applicable) in the static analysis report 308. The report may be generated by the static analysis engine or by a coordinator 304 which may be configured to receive information from the static analysis engine 306 (or by another appropriate component). As one example, static analysis of malware may include performing signature-based analysis. In some embodiments, the collected information is stored in a database record about the sample (e.g., in database 316) instead of, or in addition to, a separate static analysis report 308 being generated (i.e., a portion of the database record forms report 308). In some embodiments, the static analysis engine also forms a decision about the application (e.g., “safe”, “suspicious”, or “malicious”). For example, if an application contains even one "malicious" static feature (e.g., the application contains a hard link to a known malicious domain), the determination may be "malicious." For example, points may be assigned to each feature (e.g., based on severity if found, based on how reliable the feature is in predicting malice, etc.). Then, based on the number of points associated with the static analysis results, the static analysis engine 306 (or, if applicable, the coordinator 304) may assign a determination.

[0067] Once the static analysis is complete, the coordinator 304 finds an available dynamic analysis engine 310 to perform dynamic analysis on the application. Similar to the static analysis engine 306, the analysis system 300 may directly include one or more dynamic analysis engines. In other embodiments, dynamic analysis is performed by a separate dynamic analysis server, which includes multiple workers (i.e., multiple instances of the dynamic analysis engine 310).

[0068] Each dynamic analysis worker manages virtual machine instances (e.g., emulation / sandbox analysis of samples for malware detection, such as the C2 malware detection described above based on monitored network traffic activity). In some embodiments, the results of static analysis (e.g., performed by static analysis engine 306) are provided as input to dynamic analysis engine 310, whether in report format (308) and / or stored in database 316 or otherwise. For example, static report information may be used to help select / customize virtual machine instances used by dynamic analysis engine 310 (e.g., Microsoft Windows 7 SP2 vs. Microsoft Windows 10 Enterprise, or iOS 11.0 vs. iOS 12.0). If multiple virtual machine instances are running concurrently, a single dynamic analysis engine may manage all instances, or multiple dynamic analysis engines may be used where applicable (e.g., each managing its own virtual machine instances). During the dynamic part of the analysis, as will be described in more detail below, actions performed by the application (including network activity) are analyzed.

[0069] In various embodiments, static analysis of a sample is omitted or performed by a separate entity, where applicable. As one example, conventional static and / or dynamic analysis may be performed on a file by a first entity. Once a given file is determined to be malicious (e.g., by the first entity), the file may be provided to a second entity (e.g., an operator of security platform 122) for additional analysis of the use of malware in network activity (e.g., by the dynamic analysis engine 310).

[0070] The environment used by the analysis system 300 is instrumented / hooked so that any behavior observed while the application is running is logged as it occurs (e.g., using a customized kernel that supports hooking and logcat). Network traffic associated with the emulator is also captured (e.g., using pcap). Log / network data may be stored as temporary files on the analysis system 300. It may also be stored more permanently (e.g., using HDFS, or another suitable storage technology, or a combination of technologies such as MongoDB). A dynamic analysis engine (or another suitable component) can compare connections made by the sample to a list (314) such as domains, IP addresses, etc., and determine whether the sample communicated with (or attempted to communicate with) a malicious entity.

[0071] Similar to the static analysis engine, the dynamic analysis engine stores the results of its analysis in a record associated with the application being tested in the database 316 (and / or, if applicable, includes the results in report 312). In some embodiments, the dynamic analysis engine also forms a decision about the application (e.g., “safe,” “suspicious,” or “malicious”). For example, the determination may be “malicious” even if the application has performed only one “malicious” action (e.g., an attempt to contact a known malicious domain was made, or an attempt to extract sensitive information was observed). For another example, points may be assigned to an action performed (e.g., based on severity if found, based on how reliable the action is in predicting malice, etc.). The determination may then be assigned by the dynamic analysis engine 310 (or, if applicable, the coordinator 304) based on the number of points associated with the dynamic analysis results. In some embodiments, the final determination associated with the sample is made (e.g., by the coordinator 304) based on a combination of reports 308 and 312.

[0072] Application access visibility using Application Access Analyzer (AAA)

[0073] Figure 4 illustrates one exemplary Secure Access Service Edge (SASE) and network environment illustrating the technical challenges for application access visibility according to several embodiments. Specifically, Figure 4 shows a home office 402 (e.g., via a VPN connection, such as using a GlobalProtect (GP) VPN tunnel as shown) and a branch office 404 (e.g., via a secure remote network as shown) networking with a SASE shown as Prisma Access 406 (e.g., Prisma Access is a SASE commercially available from Palo Alto Networks, headquartered in Santa Clara, CA) via a network / ISP shown as 410A. The SASE / Prisma Access 406 network communicates with a data center 412 and a SaaS / IaaS 414 via a network / ISP shown as 410B.

[0074] Multiple computing components / entities, and network connectivity between these different computing components / entities, generally make it technically difficult for customers (e.g., customer network operations centers (NOCs), and / or IT / help desk personnel) to determine the root cause of any application connectivity problem. As a primary focus of SASE / Prisma Access 406, as shown in 408, the disclosed technology for application access analyzers provides customers / customer NOCs with automated tools to analyze and detect potential access problems for users / groups of users to access one or more applications (e.g., SaaS / private apps), including various embodiments, which are further described below.

[0075] Specifically, the disclosed technologies for Application Access Analyzer (AAA) address a variety of technical issues, as described below. The Mean Time to Detect (MTTD) and Mean Time to Recover (MTTR) of application access problems are typically in hours, which can increase application downtime and negatively impact customer / user productivity and corporate revenue. Troubleshooting and debugging generally require expertise in domain knowledge. Furthermore, correlating and tracing multiple factors to perform Root Cause Analysis (RCA), when done manually, is often cumbersome and error-prone.

[0076] For example, enterprises and / or cloud service providers with multiple hosted network services, large network infrastructures, and complex security policy configurations may encounter significant challenges in reducing the MTTR of App Access issues.

[0077] As another example, identifying RCA within a corporate organization may generally require a comprehensive check across various domains, including network connectivity, infrastructure reachability, infrastructure availability, and security policy reasoning.

[0078] The disclosed Application Access Analyzer (AAA) provides an effective and efficient solution to the aforementioned problems, as will be further described below.

[0079] Figures 5A and 5B illustrate one exemplary interface for an Application Access Analyzer (AAA) according to several embodiments. Referring to Figure 5A, the AAA illustrates a natural language (NL) query (NLQ) interface for operators to detect application connectivity, reachability (e.g., infrastructure / network reachability), and permission issues, as shown in 502.

[0080] Referring to Figure 5B, the disclosed AAA solution can provide actionable determinations for queries submitted by users (e.g., operators) using comprehensive analysis and checks performed within separate domains, such as Layer 3 (L3) network reachability, network topology, DNS, authentication, and security policies (e.g., security policy configuration, such as access rights for users to specific resources), as shown in 504. For example, the disclosed AAA solution can be used to identify and pinpoint root causes. It can significantly reduce the average time to detect and resolve application access problems (e.g., from hours to minutes). As another example, the disclosed AAA solution can generate human-consumable verdicts and analyses, which generally do not require IT operators to possess domain knowledge expertise to identify problems / root causes.

[0081] Figure 6A illustrates a service architecture for AAA according to several embodiments. The AAA service uses SASE / Prisma access topology, firewall configuration, security policy, firewall network operational status (e.g., routing, Forwarding Information Base (FIB), etc.), and other relevant firewall and authentication logs collected by the SASE / Prisma Access Insight / AIOP platform to provide comprehensive connectivity analysis. Specifically, Figure 6A shows an exemplary implementation of the Application Access Analyzer (AAA) service shown in 608, and provides a high-level view of the various components and data sources used in providing information for application connectivity analysis. Degradation and failure can generally occur due to a variety of reasons, as further described below.

[0082] In one exemplary implementation, the AAA service (608) provides an automated solution for fault isolation and reducing the average time to detect and remediate problems. Specifically, the AAA service checks for the following issues: user authentication, application access topology, network services (e.g., DNS, authentication servers, etc.), SASE access nodes (e.g., prima access nodes such as mobile gateways (MUs), portals, remote networks (RNs), service connections (SCs), etc.), network reachability / connectivity (e.g., routes, etc.), security policy analysis (e.g., formal methods to verify permissions / access to networks / services / resources), logs from various different sources (e.g., SASE / PA nodes, VPN / GP logs, traffic logs, etc.), and / or known incidents affecting connectivity (e.g., known ISP outages, cloud provider outages, internal SASE / PA issues including underlying connectivity problems, etc.).

[0083] Similarly, as mentioned above, the AAA service can also automatically generate human-consumable and actionable judgments (e.g., summary reports / alerts). The analysis can cover: (1) infrastructure issues (e.g., SASE / PA internal tunnels, nodes, root routing, overlay routing, etc.), (2) customer network service issues (e.g., reachability to DNS servers, LDAP, Radius, etc.), (3) client connectivity issues, including VPN / GP client connectivity issues (e.g., the AAA service can utilize ADEM (agent details and MTR) logs to analyze client connectivity issues (e.g., ADEM is commercially available from Palo Alto Networks, headquartered in Santa Clara, CA, or other commercially available or open-source endpoint agents can be used as well)), (4) SaaS application connectivity issues, including SaaS application reachability issues, and (5) private application connectivity issues, including private application reachability issues.

[0084] Figure 6B is a table summarizing various different data sources used in an exemplary problem, which are analyzed using the AAA service (608) according to several embodiments.

[0085] Referring to Figure 6A, the AAA service 608 is implemented on a Kubernetes cluster 610 as a container service to facilitate scalability (for example, another container-based or similar computing environment could similarly be used to implement the AAA service). The AAA service 608 includes the following components: a user authentication / traffic analysis component 612, a network access analysis component 614, and a security policy analysis component 616 (for example, a network and security analysis playbook service may accept requests from the AAA service). In one exemplary implementation, the playbook is implemented as individual modules that perform specific user authentication, network connectivity, and security policy checks, as further described below (for example, implemented in Python® or another high-level programming language). The AAA service 608 is the core service that implements user connectivity checks. AAA Service 608 utilizes multiple network connectivity and security analysis playbooks, running locally or as a playbook engine service, to collect evidence and determine potential root causes of failures, as further described below.

[0086] The AAA service 608 communicates over the network with cloud storage 604 (a cloud-based data store may be used, such as Google Cloud, AWS, or a commercially available cloud-based storage solution from another vendor). The user authentication / traffic analysis component 612 communicates over the network with the BigQuery CDL database 618 (for example, storing traffic logs). The network access analysis component 614 communicates with the Cosmos database 620, which includes the BigQuery database, the Cloud SQL database, and the graph database, as shown in Figure 6A. The network access analysis component 614 and the security policy analysis component 616 communicate with the PA firewall 102 (an instance of a commercial firewall, such as a Palo Alto Networks (PA) firewall or another commercial firewall) via an API (for example, the PA Command Framework API) to query the firewall (102) in real time, for example (for example, querying firewall operational status information).

[0087] The AAA service 608 also communicates with the PA AIOP data service component 602 over the network. Specifically, the AAA service 608 communicates with the PA AIOP data service component 602 over the network via a publish / subscribe (PubSub) communication mechanism, as shown in 606.

[0088] As also shown in Figure 6A, the PA AIOP data service component 602 communicates with the user interface (UI) component 622 via an API. This container provides an API interface for the UI (e.g., an NL query UI). This service is a general-purpose service that implements APIs for all PA AIOP services on the Cosmos platform. The AAA service can accept connectivity analysis requests from the UI and expose specific endpoints to render the corresponding results of the analysis. Furthermore, the AAA service provides a natural language (NL) query interface for users to analyze access issues (e.g., NL queries can be processed as structured queries and sent to the AAA service).

[0089] For example, the disclosed AAA services may be used to check connectivity between: (1) users / users / user groups to SaaS applications; (2) users / users / user groups to private applications hosted on a premises data center or remote branch office; (3) users / users / user groups to remote site connectivity (e.g., remote branch (RN) or data center (SC)); (4) a site to a network; and (5) a site to another site.

[0090] Figure 6C is a sequence diagram of an application connectivity analyzer using AAA services, according to several embodiments.

[0091] In 631, the data service receives a connectivity query string "user to app". The UI accepts the NLQ query, as described above with respect to Figure 6A.

[0092] In step 632, the data service creates a folder (e.g., a Google Cloud Services (GCS) folder) for each request and creates an entry in the AAA query's Big Query (BQ) table. The UI can retrieve the query status from the App Access Analyzer query table. The data service then posts the query string, along with the GCS folder information, to the AAA service via a PubSub message. The final results of the analysis are updated in the GCS folder and the BQ table.

[0093] In 633, the AAA service parses the query string and calls one or more playbooks to analyze the user / multiple users for application connectivity.

[0094] In version 634, the playbook engine / authentication analysis playbook collects user authentication information. The results are published in the GCS folder and BQ table, and the playbook status is updated in the BigQuery table.

[0095] In 635, the playbook engine / network connectivity analysis utilizes network service analysis to check network connectivity between the requested source and destination, and the determination may be updated as shown in 635A and 635B. Network service analysis is performed as follows: analyzing the connectivity of network service endpoints (e.g., DNS servers, authentication servers, etc.) and application connectivity (e.g., verifying user-to-application connectivity). Network connectivity analysis uses the following sources for analysis: instance status, tunnel status, instance metrics, etc. (e.g., those available on the Cosmos platform), Cortex Data Lake (CDL) logs (e.g., a data repository for storing user application traffic logs), and firewall routing information. The results of the analysis and the state of the playbook are stored in GCS folders and BQ tables.

[0096] In one example implementation, user-to-application connectivity analysis utilizes the following playbook, as further described below: (1) user authentication analysis, (2) network service connectivity analysis, (3) network service security policy analysis, (4) user network connectivity analysis, and (5) user security policy analysis.

[0097] In this exemplary implementation, the user authentication analysis playbook analyzes the firewall authentication log for user authentication status. The user authentication analysis playbook uses the following input parameters: [Table 1]

[0098] The user authentication analysis playbook returns user authentication status, device information, and gateway information for further analysis.

[0099] In this exemplary implementation, the network service connectivity analysis playbook utilizes the following input parameters: [Table 2]

[0100] Network service IP addresses for authentication servers, DNS servers, etc., are fetched from the user-provided configuration.

[0101] In this exemplary implementation, the user network connectivity analysis playbook utilizes the following input parameters. [Table 3]

[0102] For example, a DNS lookup on a firewall can map to multiple IP addresses. A connectivity check analysis is performed for all IP addresses. The connectivity check passes if all IP addresses are reachable. If the reachability of any IP address fails, a partial failure is returned in the result, along with the relevant analysis. If none of the IP addresses are reachable, the connectivity check fails.

[0103] In this exemplary implementation, the AAA service invokes the official security policy analysis component (for example, implemented as the official security policy analysis library) using the following input parameters: [Table 4] TIFF2026515745000006.tif164170

[0104] The formal method security analysis function returns the following results: [Table 5] TIFF2026515745000008.tif164170 TIFF2026515745000009.tif121170

[0105] The AAA service uses security policy summary results to determine whether the security policy allows or denies access.

[0106] In this exemplary implementation, the AAA service checks all user-configured DNS servers. The AAA service relies on ADEM probe (ping and curl) test results (e.g., active probing to perform application health analysis, such as for SaaS / private applications), collects unique DNS servers from the test results, and then checks or performs the following: (1) the connectivity of the DNS servers from each entry node (e.g., mobile gateway (MU) or remote network (RN)) instance, (2) L3 forwarding path tracing to the DNS servers by executing test FIB lookup commands for each unique DNS server IP found in the test results, (3) topology updates for DNS server connectivity based on the L3 forwarding path, and (4) queries each entry firewall instance to look up the match rules for each DNS server. The DNS analysis results are returned in the results dictionary under the key "DNS" as follows: In other words, for each DNS server, the results include a matching rule that highlights which domain names are resolved by a particular DNS server, L3 forwarding results, and a security policy (if any) that prevents connectivity to the DNS server. [Table 6] TIFF2026515745000011.tif220170

[0107] In this exemplary implementation, the AAA service relies on ADEM test results to check the connectivity of the authentication servers. Specifically, the AAA service queries ADEM ping / curl test results for unique authentication servers. The AAA service summarizes the authentication server status for each entry node. The authentication server results are returned in a result dictionary under the key "auth". [Table 7] TIFF2026515745000013.tif121169

[0108] In 636, the security policy analysis performs a formal methodological analysis of the security policy for the following purposes: network service endpoint connectivity and application connectivity, and the determination may be updated as shown in 636A and 636B. The results of the analysis and the state of the playbook are stored in the GCS folder and BQ table.

[0109] In 637, the AAA service updates the status in the GCS folder and BQ table based on the results received from each playbook.

[0110] In step 638, the AAA service summarizes the connectivity analysis using the final results and updates the analysis status to complete.

[0111] Figure 7 shows AAA in operation according to several embodiments. As shown in Figure 7, the AAA service (for example, shown as App Analyzer in Figure 7) includes an interface for user queries, a reporting component for generating comprehensive reports on root cause analysis (RCA) and recommended remediation, and an alerting module for generating alerts in response to identified events / incidents. The AAA service also implements various DAGs, shown as analytical DAG components, including root cause playbooks for user authentication, infrastructure network, customer network, security policy, and ISP & SaaS. The AAA service can communicate with various data sources that can correlate telemetry logs from various sources, such as VPN logs (e.g., GlobalProtect (GP) logs), SASE Autonomous Digital Experience Management (ADEM) logs (e.g., Prisma ADEM logs), tunnel logs (e.g., VPN tunnel logs such as GP tunnel logs), security entity / firewall instance logs, and traffic logs. The AAA service includes a command framework (for example, one that runs in the cloud, e.g., using Amazon Web Services (AWS) or another commercial cloud solution) that communicates with the firewall interface, such as Prisma Access as shown in Figure 7.

[0112] Referring to Figure 7, in 702, AAA provides the customer NOC with a query interface (e.g., the NLQ interface described above with respect to Figures 5A and 5B) to troubleshoot application connectivity issues, as described herein with respect to various embodiments.

[0113] In 704, AAA runs a DAG (for example, a root cause playbook as shown in Figure 7) to identify root causes for troubleshooting various application connectivity issues, including root cause playbooks for user authentication, infrastructure network, customer network, security policy, and ISP & SaaS.

[0114] In 706, the root cause playbook of the analysis DAG component uses logs from various sources to perform authentication (e.g., user authentication), security (e.g., security policies), and network connectivity (e.g., infrastructure networks and customer networks, as well as ISP and SaaS network access / connectivity issues) analyses.

[0115] In 708, the application analytics DAG uses one or more playbooks to collect evidence including telemetry logs from various sources, such as VPN logs (e.g., Global Protect (GP) logs), SASE Autonomous Digital Experience Management (ADEM) logs (e.g., Prisma ADEM logs), tunnel logs (e.g., VPN tunnel logs such as GP tunnel logs), security entity / firewall instance logs, and traffic logs, and correlates events, as shown in Figure 7.

[0116] In 710, the root cause playbook of the analysis DAG component also queries the firewall (e.g., the firewall instance of Prisma Access SASE using a firewall interface as shown in Figure 7) for further network fault isolation.

[0117] In 712, based on automated user authentication, network, and security policy analysis, the AAA / App Access Analyzer provides comprehensive reporting and potential remediation steps using the reporting and / or alerting module, as shown in Figure 7.

[0118] Figure 8 shows one exemplary implementation of AAA that incorporates domain knowledge in the form of a playbook and performs playbook analysis through the execution of a directed acyclic graph (DAG), according to several embodiments. Similarly, as mentioned above, the AAA service can be configured to implement various DAGs. Specifically, Figure 8 shows the processing of the "Can Mobile User" DAG that can be performed by the AAA service.

[0119] Referring to Figure 8, an exemplary "Can Mobile User" DAG is implemented as shown in 802, and it includes the following parameters: username, the access application specified by the Fully Qualified Domain Name (FQDN) as the target of the user's access analysis, and the prima access location specified by the location associated with the user's device, specified by the device name.

[0120] In 804, the parser extracts keywords from the "Can Mobile User" DAG and maps the extracted keywords to the "Can Mobile User" DAG, including the parameters mentioned above: username, FQDN, location, and device name.

[0121] In 806, after the process initializes the extracted DAG parameters, which include checks performed by the result placeholder, the process proceeds to the user playbook to perform user connectivity checks, user profiling, and user group checks.

[0122] In 808, the infrastructure playbook includes performing an active portal check for user connectivity. The process then proceeds to a mobile gateway instance health check, a location health check, and an infrastructure DNS server check. As shown in the diagram, the infrastructure playbook also includes performing an authentication server check for user / user group checks.

[0123] At step 810, the process proceeds to the network playbook. At this stage of the DAG process, the network playbook process includes performing a DNS resolution check in response to the mobile gateway instance health check, and then the process proceeds to the application connectivity check. The network playbook process also includes performing a DNS server connectivity check in response to the DNS server check.

[0124] At 812, the process proceeds to the security playbook. At this stage of DAG processing, the security playbook processing includes performing a policy analysis (e.g., a security policy analysis).

[0125] At step 814, the process proceeds to the application playbook. At this stage of the DAG process, the application playbook process includes performing an Autonomous Digital Experience Management (ADEM) connectivity check.

[0126] Finally, as shown in 816, the health check results of the DAG processing from the infrastructure playbook, network playbook, security playbook, and application playbook are completed and provided to the results processing stage.

[0127] As will be obvious to those skilled in the art, various other DAGs can be similarly implemented using AAA services and associated playbooks and service infrastructure.

[0128] Various use case scenarios for the disclosed AAA solution will be described further below.

[0129] Use case scenarios

[0130] As a first exemplary use case scenario, the disclosed AAA solution may be applied to facilitate effective and efficient root cause and / or other analysis of user and / or group user access from a mobile user gateway to a SaaS application.

[0131] As a second exemplary use case scenario, the disclosed AAA solution may be applied to effectively and efficiently facilitate root cause and / or other analysis of user and / or group user access to an on-premises data center or remote branch office where a private application is hosted.

[0132] As a third exemplary use case scenario, the disclosed AAA solution may be applied to facilitate effective and efficient root cause and / or other analysis of user and / or group user access from a remote site to a remote branch or data center.

[0133] Various process embodiments for the Application Access Analyzer (AAA) are described further below.

[0134] Exemplary process for Application Access Analyzer (AAA) service

[0135] Figure 9 is a flowchart relating to a process for an AAA service according to several embodiments. In some embodiments, the process 900 shown in Figure 9 is performed by an AAA service and technique similarly described above, including embodiments described with respect to Figures 4-8.

[0136] In 902, access to applications is monitored across the network, similar to what was described above with respect to Figures 4-8.

[0137] In 904, the root cause of network-wide application access and related issues for a user (e.g., a specified user or group of users) is automatically determined using an application access analyzer, as described above with respect to Figures 4-8.

[0138] In 906, as described above with respect to Figures 4-8, actions are taken in response to determining the root cause of the user's access to applications across the network and related problems.

[0139] Figure 10 is another flowchart relating to a process for an AAA service according to several embodiments. In some embodiments, process 1000 as shown in Figure 10 is performed by AAA services and techniques similarly described above, including embodiments described with respect to Figures 4-8.

[0140] In 1002, access to the application is monitored across the network, similar to what was described above with respect to Figures 4-8.

[0141] In 1004, the root cause of access to applications across the network and related problems (for example, for a specified user or group of users) is automatically determined using an application access analyzer, as described above with respect to Figures 4-8.

[0142] In 1006, users provide access to applications across the network and related queries. For example, the application access analyzer can support the processing of natural language queries, as described above with respect to Figures 4-8 (e.g., NL queries may be processed and sent to the AAA service as structured queries).

[0143] In 1008, as described above with respect to Figures 4-8, the Application Access Analyzer is used to generate a report that summarizes the root causes of problems related to network access to applications (for example, for a specified user or group of users).

[0144] Figure 11 is another flowchart relating to a process for an AAA service according to several embodiments. In some embodiments, process 1100 as shown in Figure 11 is performed by AAA services and techniques similarly described above, including embodiments described with respect to Figures 4-8.

[0145] Referring to Figure 11, a natural language query (NLQ) is received and processed using the AAA service described above, as shown in 1102. The AAA service automatically performs various analyses, including (1) user and endpoint analysis, as shown to begin in 1104, (2) network analysis, as shown to begin in 1106, and (3) security policy analysis, as shown to begin in 1108, as shown in Figure 11, each of which is further described below.

[0146] Referring to the user and endpoint analysis shown to begin at 1104 in Figure 11, the process begins at 1110 by determining whether the user is a valid user. If not, the determination is Unknown because the user cannot be found, as shown at 1112. Otherwise, the process proceeds to 1114, where the AAA service retrieves user and gateway (GW) information, as well as connected device information associated with the user. At 1116, it is determined whether the user was authenticated. If not, the determination is set as user authentication (Auth) failure, as shown at 1118. At 1122 (e.g., user authentication was verified), it is determined whether the mobile GW is up and running. If not, the determination is set to be down, as shown at 1124. At 1126 (for example, it is verified that the mobile GW is up and running), the determination is then decided as Yes for the user, the user's endpoint device, and the GW, and this information is provided to the final determination analysis as shown at 1158. Once user authentication is successful and it is verified that the GW is up and running, the process also proceeds from 1116 and 1122 to 1120. At 1128, the AAA service verifies the health of the authentication server and its reachability from the GW. At 1130, the determination is decided as Yes for the authentication analysis and renders the health and reachability of the authentication server. This determination information is then sent to the final determination analysis at 1158.

[0147] Referring to the network analysis shown to begin at 1106 in Figure 11, the process begins at 1132 by determining whether a network route exists from the GW to the DNS server. If not, the determination is set as a DNS resolution failure, as shown at 1134. Otherwise, the process proceeds to perform an automated discovery of the network topology for DNS, as shown at 1136. At 1138, the AAA service determines the health of the DNS server and its reachability from the GW. At 1140, the determination is set as Yes for the DNS analysis and the network topology is rendered. This determination information is then sent to the final determination analysis, as shown at 1158. As shown at 1142, the network analysis includes determining whether a network route exists from the GW to the application (e.g., SaaS / private application). If not, the determination is set as no network route exists from the GW to the application, as shown at 1144. Otherwise, the process proceeds to perform an automated discovery of the network topology for the app, as shown in 1146. In 1148, the AAA service determines the health of the app and its reachability from the GW. In 1150, the determination is decided as Yes for the network analysis and rendered for the network topology. This determination information is then sent to the final determination analysis in 1158.

[0148] Referring to the security policy analysis shown to begin at 1108 in Figure 11, the process begins at 1152 by determining whether access is denied using a policy (e.g., a security policy). If so (i.e., access is denied under the security policy), the determination is set to NO, as access is denied under the security policy, as shown at 1154. Otherwise (i.e., access is not denied under the security policy), the determination is set to Yes, as a security policy match has been found, and this determination information is sent to the final determination analysis at 1158.

[0149] While the embodiments described above have been explained in some detail for the purpose of clarifying understanding, the present invention is not limited to the details provided. Many alternative methods exist for carrying out the present invention. The disclosed embodiments are illustrative and not limiting.

Claims

1. A system including a processor and memory, The aforementioned processor, Monitor access to applications across the network, Using an application access analyzer, the root cause of problems related to a user's access to the application across the network is automatically determined, and, In response to determining the root cause of the problem related to the user's access to the application across the network, take action. It is configured in such a way, The aforementioned memory is Coupled with the aforementioned processor, and Give instructions to the aforementioned processor, It is structured in such a way. system.

2. The application access analyzer determines the root cause of the user's access to the application across the network and related problems by correlating multiple data sources across multiple domains using artificial intelligence and / or machine learning, and The aforementioned multiple domains include network, authentication, DNS, SaaS / private application health, and security policy configuration. The system according to claim 1.

3. The application access analyzer automatically detects network connectivity anomalies and / or performance degradations related to the user's or group of users' access to the application across the network. The system according to claim 1.

4. The aforementioned action includes generating a human-consumable and actionable decision analysis that detects application connectivity problems and reduces the average time to remediate them. The system according to claim 1.

5. Using the application access analyzer, automatically determining the root cause of the problem related to the user's access to the application across the network is: This includes identifying network infrastructure issues, customer network service issues, client connectivity issues, SaaS / private application (app) health issues, and / or other connectivity / reachability or performance degradation issues. The system according to claim 1.

6. The application access analyzer automatically discovers the network topology used by the user to access the application. The system according to claim 1.

7. The aforementioned application access analyzer performs a security attitude assessment by constructing a unified logical model for calculations regarding the corporate network and associated security policies. The system according to claim 1.

8. The aforementioned processor further, The aforementioned application access analyzer is used to monitor network topology problems. The system according to claim 1, configured as described above.

9. The aforementioned processor further, The aforementioned application access analyzer is used to monitor network configuration problems. The system according to claim 1, configured as described above.

10. The aforementioned processor further, The aforementioned application access analyzer is used to monitor network service problems. The system according to claim 1, configured as described above.

11. The aforementioned processor further, The aforementioned application access analyzer is used to monitor security policy issues. The system according to claim 1, configured as described above.

12. The aforementioned processor further, The application access analyzer's natural language query interface is used to process user queries. The system according to claim 1, configured as described above.

13. It is a method, Steps to monitor access to the application across the network, The steps include using an application access analyzer to automatically determine the root cause of problems related to a user's access to the application across the network, A step of taking action in response to determining the root cause of the problem related to the user's access to the application across the network, Methods that include...

14. The application access analyzer determines the root cause of the user's access to the application across the network and related problems by correlating multiple data sources across multiple domains using artificial intelligence and / or machine learning, and The aforementioned multiple domains include network, authentication, DNS, SaaS / private application health, and security policy configuration. The method according to claim 13.

15. The application access analyzer automatically detects network connectivity anomalies and / or performance degradations related to the user's or group of users' access to the application across the network. The method according to claim 13.

16. The aforementioned action includes generating a human-consumable and actionable decision analysis that detects application connectivity problems and reduces the average time to remediate them. The method according to claim 13.

17. The step of using the application access analyzer to automatically determine the root cause of the problem related to the user's access to the application across the network is: This includes identifying network infrastructure issues, customer network service issues, client connectivity issues, SaaS / private application (app) health issues, and / or other connectivity / reachability or performance degradation issues. The method according to claim 13.

18. The application access analyzer automatically discovers the network topology used by the user to access the application. The method according to claim 13.

19. The aforementioned application access analyzer performs a security attitude assessment by constructing a unified logical model for calculations regarding the corporate network and associated security policies. The method according to claim 13.

20. A computer program stored on a non-temporary computer-readable storage medium, The aforementioned computer program includes a plurality of instructions, and when the instructions are executed, Steps to monitor access to the application across the network, The steps include using an application access analyzer to automatically determine the root cause of problems related to a user's access to the application across the network, A step of taking action in response to determining the root cause of the problem related to the user's access to the application across the network, To have the computer perform this task. Computer program.

Images