Security policy analysis

Abstract

A security policy analysis is disclosed. Configuration information containing at least one policy is received. A model is built using the received configuration information, which includes normalizing the policy. A policy analysis is performed using the policy, which includes performing a pre-change analysis associated with the proposed policy change. The results of the policy analysis are provided as output.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims priority to U.S. Provisional Patent Application No. 63 / 459,494, filed Apr. 14, 2023, entitled "APPLICATION ACCESS ANALYZER", U.S. Provisional Patent Application No. 63 / 459,492, filed Apr. 14, 2023, entitled "SECURITY POLICY ANALYSIS - DEVOPS APPROACH", and U.S. Provisional Patent Application No. 63 / 459,500, filed Apr. 14, 2023, entitled "TOPOLOGICAL CO - RELATION", all of which are hereby incorporated by reference in their entirety for all purposes.

[0002] [Technical Field] Malware is a common term often used to refer to malicious software (e.g., including various hostile, intrusive, and / or otherwise unwanted software). Malware can be in the form of code, scripts, active content, and / or other software. Examples of malware use include interfering with computer and / or network operations, stealing confidential information (e.g., secrets such as identity, financial, and / or intellectual property - related information), and / or obtaining access to private / proprietary computer systems and / or computer networks. Unfortunately, as techniques are developed to help detect and 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 the accompanying drawings. [Figure 1]This is an example of an environment where malicious applications ("malware") are detected and prevented from causing harm. [Figure 2A] This shows one embodiment of a data appliance. [Figure 2B] This is a functional diagram of the logical components of one embodiment of a data appliance. [Figure 3] Here are some examples of logical components that can be included in a system for analyzing samples. [Figure 4] This is an exemplary Secure Access Service Edge (SASE) and network environment illustrating technical challenges for application access visibility through several embodiments. [Figure 5A] This document presents exemplary interfaces for an Application Access Analyzer (AAA) in several embodiments. [Figure 5B] This document illustrates exemplary interfaces for AAA in several embodiments. [Figure 6A] This document presents several service architectures for AAA (Multi-Audio Access). [Figure 6B] This is a table summarizing the data sources used in exemplary problems analyzed using AAA Services in several embodiments. [Figure 6C] This is a sequence diagram of an Application Connectivity Analyzer using AAA services in several embodiments. [Figure 7] Several embodiments of AAA in operation are shown. [Figure 8] Here is an example of a simplified security policy. [Figure 9A] The modeled policy is shown. [Figure 9B] The modeled policy is shown. [Figure 9C] The modeled policy is shown. [Figure 9D] Shows a modeled policy. [Figure 10] Shows various examples of potentially problematic security policies. [Figure 11] Shows an exemplary interface. [Figure 12] Shows an exemplary interface. [Figure 13] Shows an exemplary interface. [Figure 13-1] Shows an exemplary interface. [Figure 14] Shows an exemplary interface. [Figure 14-1] Shows an exemplary interface. [Figure 14-2] Shows an exemplary interface. [Figure 15] Shows an exemplary interface. [Figure 15-1] Shows an exemplary interface. [Figure 16] Shows an exemplary interface. [Figure 17] Shows an exemplary interface. [Figure 17-1] Shows an exemplary interface. [Figure 18] Shows an exemplary interface. [Figure 18-1] Shows an exemplary interface. [Figure 18-2] Shows an exemplary interface. [Figure 19] Shows an exemplary interface. [Figure 20] Shows an exemplary interface. [Figure 21] Shows an exemplary interface. [Figure 22] Is a flowchart of an exemplary process for using security policy analysis in various ways according to various embodiments. [Figure 23A] Shows examples of alert / incident codes and display names. [Figure 23A-1] Examples of alert / incident codes and display names are shown. [Figure 23B] Examples of alert / incident codes and display names are shown. [Figure 23B-1] Examples of alert / incident codes and display names are shown. [Figure 23C] Examples of alert / incident codes and display names are shown. [Figure 24A] An exemplary architecture is shown. [Figure 24B] An exemplary architecture is shown. [Figure 24C] An exemplary architecture is shown. [Figure 24D] An exemplary architecture is shown. [Figure 25] An exemplary workflow for policy change management is shown. [Figure 26] An exemplary architecture is shown. [Figure 27A] Various workflows are shown. [Figure 27B] Various workflows are shown. [Figure 27C] Various workflows are shown. [Figure 27D] Various workflows are shown. [Figure 28] Examples of user group-based incidents are shown. [Figure 28-1] Examples of user group-based incidents are shown. [Figure 29] An exemplary architecture is shown. [Figure 30] An exemplary communication diagram associated with the user-to-group mapping collector service is shown. [Figure 31A] A part of the incident resolution analysis report is shown. [Figure 31A-1] A part of the incident resolution analysis report is shown. [Figure 31B] A part of the incident resolution analysis report is shown. [Figure 31B-1] A part of the incident resolution analysis report is shown. [Figure 32] This figure shows an example of a new rule-intent satisfaction analysis report. [Figure 32-1] This figure shows an example of a new rule-intent satisfaction analysis report. [Figure 33] Figure 32 shows details of various parts of the report. [Figure 33-1] Figure 32 shows details of various parts of the report. [Figure 33-2] Figure 32 shows details of various parts of the report. [Figure 34A] Here is an example of a breakdown card. [Figure 34A-1] Here is an example of a breakdown card. [Figure 34B] Here is an example of a breakdown card. [Figure 34B-1] Here is an example of a breakdown card. [Figure 35] Here are some examples of security policy anomaly / hit count result reports. [Figure 35-1] Here are some examples of security policy anomaly / hit count result reports. [Figure 36A] This document illustrates various forms of security policy incident reports. [Figure 36A-1] This document illustrates various forms of security policy incident reports. [Figure 36A-2] This document illustrates various forms of security policy incident reports. [Figure 36B] This document illustrates various forms of security policy incident reports. [Figure 36B-1] This document illustrates various forms of security policy incident reports. [Figure 36B-2] This document illustrates various forms of security policy incident reports. [Figure 36C] This document illustrates various forms of security policy incident reports. [Figure 36C-1]This document illustrates various forms of security policy incident reports. [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 processors, such as processors, which are stored on and / or provided by memory coupled to a processor. These implementations, or any other forms the 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 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 diagrams 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 only by the claims, and the present invention encompasses numerous alternative forms, modifications, and equivalents. In order to provide a complete understanding of the present invention, numerous specific details are described in the following description. These details are provided for illustrative purposes, 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 relating to the present invention are not described in detail so as not to unnecessarily obscure the present invention.

[0006] I. Introduction

[0007] A firewall generally allows authorized communications to pass through the firewall while protecting a network from unauthorized access. A firewall is typically 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 into or run as one or more software applications on various types of devices such as computer servers, gateways, network / routing devices (e.g., network routers), and data appliances (e.g., security appliances or other types of dedicated devices), and in various implementations, specific operations may be implemented in dedicated hardware such as ASICs or FPGAs.

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

[0009] Security devices (e.g., security appliances, security gateways, security services, and / or other security devices) may include various security functions (e.g., firewalls, anti-malware, intrusion prevention / detection, data loss prevention (DLP), and / or other security functions), networking functions (e.g., routing, quality of service (QoS), workload balancing of network-related resources, and / or other networking functions), and / or other functions. For example, routing functions may be based on source information (e.g., IP addresses and ports), destination information (e.g., IP addresses and ports), and protocol information.

[0010] Basic packet filtering firewalls filter network communication traffic by inspecting individual packets transmitted over the network (e.g., first-generation firewalls, which are either packet filtering firewalls or stateless packet filtering firewalls). Stateless packet filtering firewalls typically inspect the individual packets themselves and apply rules based on the inspected packets (e.g., using a combination of the packet's source and destination address information, protocol information, and port number).

[0011] Application firewalls can also perform application layer filtering (for example, application layer filtering firewalls or second-generation firewalls that operate at the application level of the TCP / IP stack). Application layer filtering firewalls or application firewalls can generally identify specific applications and protocols (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 through standard ports (for example, unauthorized / off-policy protocols attempting to sneak through by using non-standard ports for that protocol can generally be identified using an application firewall).

[0012] A stateful firewall can also perform state-based packet inspection, where each packet is examined within the context of a set of packets associated with the packet flow of that network transmission. This firewall technique is commonly called stateful packet inspection because it can maintain a record of all connections passing through the firewall and 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.

[0013] Advanced or next-generation firewalls, as described above, can perform stateless and stateful packet filtering as well as application layer filtering. Next-generation firewalls can also perform additional firewall techniques. For example, certain newer firewalls, sometimes called advanced or next-generation firewalls, can also identify users and content (e.g., next-generation firewalls). In particular, certain next-generation firewalls extend the list of applications that these firewalls can automatically identify to thousands of applications. An example of such a next-generation firewall is commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' PA Series firewalls). For example, Palo Alto Networks' next-generation firewalls enable enterprises to identify and control applications, users, and content using not only ports, IP addresses, and packets, but also various identification techniques, such as APP-ID for precise application identification, User ID for user identification (e.g., by user or user group), and Content ID for real-time content scanning (e.g., controlling web surfing and restricting data and file transfers). These identification techniques enable enterprises to securely enable application use using business-related concepts, rather than following the conventional approach provided by traditional port-blocking firewalls. Furthermore, dedicated hardware for next-generation firewalls (e.g., implemented as a dedicated appliance) generally provides a higher level of performance for application testing than software running on general-purpose hardware (e.g., security appliances offered by Palo Alto Networks, Inc. that use dedicated, feature-specific processing tightly integrated with a single-path software engine to maximize network throughput while minimizing latency).

[0014] Advanced or next-generation firewalls can also be implemented using virtualized firewalls. Examples of such next-generation firewalls include those commercially available from Palo Alto Networks, Inc. (e.g., Palo Alto Networks' VM Series firewalls, which support a variety of commercial virtualization environments including VMware® ESXi® and NSX®, Citrix® Netscaler SDX®, KVM / OpenStack (CentOS / RHEL, Ubuntu®), and Amazon Web Services (AWS)), as well as the CN Series Container Next-Generation Firewalls. For example, virtualized firewalls can support the same or identical functionality as next-generation firewalls and advanced threat protection features available in physical form factor appliances, enabling enterprises to securely allow applications to enter and traverse their private, public, and hybrid cloud computing environments. Automation features such as VM monitoring, dynamic address groups, and REST-based APIs enable enterprises to proactively monitor VM changes and dynamically feed that context into security policies, thereby eliminating policy lag that may occur when VMs are modified.

[0015] Overview of Techniques for Application Access Analyzers

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

[0017] Specifically, identifying Software as a Service (SaaS) / private application connectivity issues in large-scale network infrastructure is technically challenging due to the vast domain that generally requires thorough checking and analysis. This significantly increases the mean time to detect and remediate problems in SaaS / private application (App) connectivity issues, especially in large-scale network infrastructure. Therefore, many Secure Access Service Edge (SASE) providers and organizations are trying to solve this problem through various methods using artificial intelligence (AI) and / or machine learning (ML) technologies. Automating the detection and remediation of application connectivity issues can reduce mean time to recovery (MTTR) and organizational operational costs. Furthermore, by providing solutions that facilitate automated detection and remediation of application connectivity issues, SASE providers can help expand their customer base with high-quality products and customer satisfaction.

[0018] Therefore, new and improved solutions for facilitating application access analysis are disclosed with respect to various embodiments.

[0019] 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 for IT help desks or other technical support personnel / users) to detect application reachability, connectivity, and access / authorization issues. The disclosed AAA facilitates automated remediation. As an example, the AAA provides actionable determinations for queries submitted by operators, using comprehensive details of analyses and checks performed in different categories (e.g., separate domains including user / endpoint analysis, networking analysis, and security policy analysis, as further described below). Specifically, the AAA automatically discovers the network topology used by a given user (e.g., user(s) specified in the query) to access a given application (e.g., a SaaS / private application specified in the query), analyzes the operational status of the underlying network infrastructure, performs user authentication analysis, checks the health and reachability of Domain Name System (DNS) and authentication (Auth) servers that the user reaches before accessing the application, and infers user or user group-specific security policies for any access / authorization issues.

[0020] Resolvable determination, root cause analysis, and problem identification significantly reduce the average time to resolve application connectivity issues. This also eliminates the time and effort that would otherwise be required for operators to debug multiple devices following runbooks / playbooks, a process that typically requires specialized knowledge.

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

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

[0023] In one embodiment, the disclosed Application Access Analyzer (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.

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

[0025] 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 remediate application connectivity issues, as further described below.

[0026] In one embodiment, the disclosed AAA can be used to perform a thorough analysis of various troubleshooting domains within a short period of time (e.g., minutes), as further described below, which would normally require a significant amount of time to troubleshoot each domain.

[0027] In one embodiment, the disclosed AAA may be used to perform analyses including identifying network infrastructure issues, customer network services, client connectivity issues, SaaS / private application (app) health, and reachability issues, as further described below. For example, the disclosed AAA can provide a workable summary for each troubleshooting domain, and operators do not need specialized knowledge to detect and remediate problems.

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

[0029] In one embodiment, the disclosed AAA may be used to provide a security posture assessment by constructing a unified logical computational model for firewall security policies.

[0030] In one embodiment, the disclosed AAA may be used to manage and maintain tracking of network topology issues, networking configuration issues, network services, and security policies, which can often be complex and 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.

[0031] In one embodiment, the disclosed AAA can incorporate expertise 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).

[0032] In one embodiment, the disclosed AAA can be used to significantly reduce the operational and support costs for a company and its users to access SaaS / private applications.

[0033] In an exemplary implementation, the disclosed AAA is implemented as the Prisma AI Operations (AIOPs) 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 AIOPs platform provides proactive monitoring, alerting, problem isolation, and playbook-driven remediation to deliver SLAs (MTTK / I, MTTR) as requested by customers.

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

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

[0036] Exemplary System Environment for Application Access Analyzer

[0037] Accordingly, in some embodiments, the disclosed techniques include providing a security platform configured to provide DPI functionality (including, for example, stateful inspection) (for example, the security function(s) / platform(s) may be implemented using a firewall (FW) / next-generation firewall (NGFW), a network sensor acting in place of a firewall, or another (virtual) device / configuration capable of implementing security policies using the disclosed techniques, such as PANOS running on a commercially available virtual / physical NGFW solution from Palo Alto Networks, Inc., or other security platforms / NGFWs, such as 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 may also be implemented and configured to perform the disclosed techniques), and this security platform may be provided, for example, as part of or as part of a SASE security solution, in which case the cloud-based security solution (e.g., SASE) may be monitored using the disclosed techniques for an application access analyzer, as further described below.

[0038] Figure 1 shows an example of an environment in which malicious applications ("malware") are detected and prevented from causing harm. As will be described in more detail below, malware classification (e.g., 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. Using the techniques described herein, devices such as endpoint client devices 104-110 can be protected from such malware (e.g., including previously unknown / new variants of malware such as C2 malware).

[0039] As used herein, “malware” refers to an application that engages in behavior that a user would not authorize or authorize if fully informed, whether secret or illegal. Examples of malware include ransomware, Trojans, viruses, rootkits, spyware, and hacking tools. An example of malware is a desktop / mobile application that encrypts a user’s stored data (e.g., ransomware). 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.

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

[0041] 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). Examples of such policies include those that manage traffic shaping, quality of service, and traffic routing. Other examples of policies include security policies that require threat scanning of 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 that remains within the corporate network 140.

[0042] An embodiment of the data appliance is shown in Figure 2A. The illustrated example 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 storage units). In various embodiments, the data appliance 102 stores information (in RAM 204, storage 210, and / or other appropriate locations) used to monitor the enterprise network 140 and implement the disclosed techniques. Examples of such information include application identifiers, content identifiers, user identifiers, requested URLs, IP address mappings, policies and other configuration information, signatures, hostname / URL categorization 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 (FPGAs) 208 configured to perform matching, function as a network processor, and / or perform other tasks.

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

[0044] Whenever the data appliance 102 is described as performing a task, a single component of the data appliance 102, a subset of components, or all components working together may perform the task. Similarly, whenever a component of the data appliance 102 is described as performing a task, a sub-component 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 may be adapted accordingly. Similarly, additional logical components / features may be included in embodiments of the data appliance 102 where applicable. An example of a component included in the data appliance 102 in various embodiments is an application identification engine configured to identify applications (e.g., using various application signatures to identify applications based on packet flow analysis). For example, the application identification engine can determine what type of traffic a session involves, such as Web Browsing - Social Networking, Web Browsing - News, SSH, etc.

[0045] Figure 2B is a functional diagram of the logical components of an embodiment of the data appliance. The illustrated examples represent 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 one or more sets of scripts (for example, written in Java®, Python, etc., where applicable).

[0046] 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 interactions, such as configuring policies and providing a user interface for viewing log data. The data plane is responsible for managing data, such as performing packet processing and session processing.

[0047] 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. When the flow module 238 identifies a packet as part of a new session, it creates a new session flow. Subsequent packets are identified as belonging to the session based on the flow lookup. If applicable, SSL decryption is applied by the SSL decryption engine 240. Otherwise, processing by the SSL decryption engine 240 is omitted. The decryption engine 240 can help the data appliance 102 inspect and control SSL / TLS and SSH encrypted traffic, and thus help block threats that might otherwise remain hidden within encrypted traffic. The decryption engine 240 can also help prevent sensitive content from leaking out of 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 decryption policies (which specify, for example, which sessions to decrypt), decryption profiles can be assigned to control various options for sessions controlled by the policy. For example, the use of specific cipher suites and encryption protocol versions may be required.

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

[0049] Based on the decision made by the application identification engine 242, the packet is sent by the threat engine 244 to the appropriate decoder, which is configured 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 a signature query to determine what should happen to the packet. If necessary, the SSL encryption engine 246 can re-encrypt the decrypted data. The packet is then forwarded (for example, to the destination) using the forwarding module 248 for transmission.

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

[0051] II. Security Platform

[0052] Returning to Figure 1, let's assume a malicious individual (using System 120) has created malware 130, such as malware for a malicious web campaign (for example, the malware could 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 hopes that a client device, such as client device 104, will execute a copy of malware 130 to unpack the malware executable file / payload, thereby compromising the client device and, for example, turning the client device into a bot in a botnet. The compromised client device may then be commanded to perform tasks (for example, cryptocurrency mining or participating in a denial-of-service attack) and report information to an external entity, such as a command and control (C2 / C&C) server 150, and, where applicable, may be commanded to receive commands from the C2 server 150.

[0053] 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 on a link to a phishing / compromised site, which could lead to 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 detects such malware 130 and blocks it from harming Alice's client device 104 by performing the disclosed techniques for sample traffic-based self-learning malware detection, as further described below.

[0054] In various embodiments, the data appliance 102 is configured to work in cooperation with the security platform 122. For 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 set includes a signature for malware 130 (e.g., the MD5 hash of malware 130), the data appliance 102 can 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 C&C 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 client device 104 attempts to contact C2 server 150, such an attempt is a strong indicator that client 104 has been compromised by malware (and accordingly, corrective measures should be taken, such as isolating client device 104 from communication with other nodes in the corporate network 140).

[0055] As will be explained 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 is sent back to the data appliance 102 to enforce security policies, thereby protecting Alice's client device 104 from the execution of the malware 130 (for example, blocking the malware 130 from access on the client device 104).

[0056] In various embodiments, if an attachment signature cannot be found, the data appliance 102 can take various actions. As a first example, the data appliance 102 may function as fail-safe by blocking the transmission of attachments that are not listed as benign (e.g., do not match the signatures of known good files). The drawback of this approach is that many legitimate attachments may be unnecessarily blocked as potential malware, even though they are actually benign. As a second example, the data appliance 102 may function as fail-danger by allowing the transmission of attachments that are not listed as malicious (e.g., do not match the signatures of known bad files). The drawback of this approach is that it does not prevent newly created malware (that has not been detected by platform 122) 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 classify it in other ways.

[0057] The security platform 122 stores a copy of the received sample in storage 142 and the analysis is initiated (or scheduled, if applicable). An example of storage 142 is an Apache Hadoop Cluster (HDFS). The results of the analysis (and any additional information related to 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, signatures can be generated for malware and distributed (e.g., to data appliances such as data appliances 102, 136, and 148) to automatically block future file transfer requests for downloading files determined to be malicious.

[0058] In various embodiments, the security platform 122 includes one or more dedicated commercial hardware servers (e.g., having a multi-core processor(s), 32G+ RAM, a Gigabit network interface adapter(s), and a hard drive(s)) running a typical server-class operating system (e.g., Linux®). 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 tasks such as data storage or data processing, it should be understood that one or more sub-components of the security platform 122 may work together (individually or in cooperation with third-party components) to perform those tasks. For example, the security platform 122 can optionally collaborate with one or more virtual machine (VM) servers, such as the virtual machine (VM) server 124, to perform static / dynamic analysis.

[0059] An example of a virtual machine server is a physical machine containing commercial server-class hardware (e.g., a multi-core processor, 32 gigabytes or more of RAM, and one or more gigabit network interface adapters) running commercial virtualization software such as 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. For example, the virtual machine server may rely on EC2, and the rest of the security platform 122 is owned by the operator of the security platform 122 and provided by dedicated hardware under its control. VM server 124 is configured to provide one or more virtual machines 126-128 for emulating client devices. The virtual machines can run various operating systems and / or versions thereof. Observed behavior resulting from running applications within the virtual machines is logged and analyzed (e.g., for signs that the application is malicious). In some embodiments, log analysis is performed by the 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.

[0060] In various embodiments, the security platform 122 makes the results of 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 any 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. The subscription may cover only 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 malware signatures known to the security platform 122.

[0061] 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 with its own corporate networks 114 and 116, and each with its own data appliances 136 and 148, 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) that provides 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 (for example, to receive content packages from the security platform 122, use the received content packages to check attachments according to the techniques described herein, and send applications to the security platform 122 for analysis).

[0062] Figure 3 shows an example of logical components that can 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 embedded in 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, such as through 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 included in collection 314 are 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 there is no existing signature associated with the sample in the analysis system 300), it is added to queue 302. As shown in Figure 3, application 130 is received by system 300 and added to queue 302.

[0065] Coordinator 304 monitors queue 302, and when a resource (e.g., a static analysis worker) becomes available, Coordinator 304 fetches a sample from queue 302 for processing (e.g., fetching a copy of malware 130). Specifically, Coordinator 305 first provides the sample to the static analysis engine 306 for static analysis. In some embodiments, one or more static analysis engines are included within the analysis system 300, and 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 in the static analysis report 308 (along with heuristics and other information, where applicable). The report may be generated by the static analysis engine or by a coordinator 304 (or another suitable component) which may be configured to receive information from the static analysis engine 306. As an example, static analysis of malware may include performing signature-based analysis. In some embodiments, the collected information is stored in the sample's database record (e.g., in database 316) instead of, or in addition to, creating a separate static analysis report 308 (i.e., a portion of the database record forms report 308). In some embodiments, the static analysis engine also forms a determination about the application (e.g., “safe”, “suspicious”, or “malicious”). As an example, a determination may be “malicious” even if the application has only one “malicious” static feature (e.g., if the application contains a hard link to a known malicious domain). As another example, each feature may be assigned points (for example, based on severity if found, or based on how reliable the feature is in predicting malice), and a judgment may be assigned by the static analysis engine 306 (or the coordinator 304, where applicable) based on the number of points associated with the static analysis results.

[0067] Once the static analysis is complete, the coordinator 304 identifies an available dynamic analysis engine 310 and performs 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 containing multiple workers (i.e., multiple instances of the dynamic analysis engine 310).

[0068] Each dynamic analysis worker manages virtual machine instances (e.g., sample emulation / sandbox analysis 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 to dynamic analysis engine 310 as input, 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 SP 2 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, if applicable, performed by a separate entity. For example, conventional static and / or dynamic analysis may be performed on a file by a first entity. If 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, particularly regarding the use of network activity by the malware (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). The log / network data is stored as temporary files on the analysis system 300 and can also be stored more persistently (e.g., using HDFS or another suitable storage technology, or a combination of technologies such as MongoDB). The dynamic analysis engine (or another suitable component) can compare the connections made by the sample to a list of domains, IP addresses, etc. (314) to 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 database 316 (and / or, if applicable, includes the results in report 312). In some embodiments, the dynamic analysis engine also forms a determination about the application (e.g., “safe,” “suspicious,” or “malicious”). For example, a determination may be “malicious” even if only one “malicious” action is performed by the application (e.g., an attempt to contact a known malicious domain is made, or an attempt to exfiltrate sensitive information is observed). In another example, points may be assigned to the action performed (e.g., based on severity, if found, or based on how reliable the action is in predicting malice), and the determination may 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 shows an exemplary Secure Access Service Edge (SASE) and network environment illustrating the technical challenges for application access visibility in several embodiments. Specifically, Figure 4 shows a home office 402 (via VPN connectivity, such as using a GlobalProtect (GP) VPN tunnel, as shown, which is a VPN solution commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, CA) and a branch office 404 (via a secure remote network, as shown), which network communicate with a SASE (shown as Prisma Access 406, for example, Prisma Access is a SASE commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, CA) via the network / ISP shown in 410A. The SASE / Prisma Access 406 network communicates with a data center 412 and a SaaS / IaaS 414 via the network / ISP shown in 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 application connectivity issues. As a primary focus of SASE / Prisma Access 406, as shown in 408, the techniques disclosed for application access analyzers provide customers / customer NOCs with automated tools to analyze and detect potential access issues when users / groups of users access one or more applications (e.g., SaaS / private applications), as will be further described below with respect to various embodiments.

[0075] Specifically, the techniques disclosed for Application Access Analyzer (AAA) address a variety of technical issues, as described below. The mean time to detection (MTTD) and mean time to recovery (MTTR) for application (App) access problems are typically in the range of hours, which can increase application downtime and negatively impact customer / user productivity and corporate revenue. Troubleshooting and debugging generally require specialized knowledge. Furthermore, correlating and tracking multiple factors to perform a root cause analysis (RCA) is often cumbersome and error-prone when done manually.

[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 application access issues.

[0077] As another example, identifying RCA within an enterprise 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 show exemplary interfaces for an Application Access Analyzer (AAA) in several embodiments. Referring to Figure 5A, the AAA provides a natural language (NL) query (NLQ) interface to an operator for detecting application connectivity, reachability (e.g., infrastructure / network reachability), and authorization issues, as shown in 502.

[0080] Referring to Figure 5B, the disclosed AAA solution, as shown in 504, can provide actionable determinations for queries submitted by users (e.g., operators) using comprehensive analysis and checks performed across different domains, including Layer 3 (L3) network reachability, network topology, DNS, authentication, and security policies (e.g., security policy configurations such as user access rights to specific resources). For example, the disclosed AAA solution can be used to identify and pinpoint root causes, which significantly reduces 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 determinations and analyses, which generally do not require IT operators to possess specialized knowledge to identify problems / root causes.

[0081] Figure 6A illustrates service architectures for AAA in several embodiments. The AAA service uses SASE / Prisma Access Topology, Firewall Configuration, Security Policy, Firewall Network Operational State (e.g., Routing, Forwarding Information Base (FIB), etc.), as well as other relevant firewall and authentication logs collected by SASE / Prisma Access Insights / AIOPs (SASE / Prisma Access Insights / AIOPs platform) to provide comprehensive connectivity analysis. Specifically, Figure 6A shows an exemplary implementation of the Application Access Analyzer (AAA) service shown in 608, providing a rough diagram of the various components and data sources used in providing information for application connectivity analysis. Degradation and outages can generally occur for a variety of reasons, as further described below.

[0082] In an exemplary implementation, the AAA service (608) provides an automated solution for isolating faults and reducing the average time to detect and remediate problems. Specifically, the AAA service checks for issues related to User Authentication, Application Access Topology, Network Services (e.g., DNS, authentication servers, etc.), SASE Access Nodes (e.g., Prisma Access Nodes such as Mobile Gateways (MUs), Portals, Remote Networks (RNs), Service Connections (SCs)), Network Reachability / Connectivity (e.g., Routes, etc.), Security Policy Analysis (e.g., Formal Methods to validate permissions / access to networks / services / resources), Logs from various different sources (e.g., SASE / PA node logs, VPN / GP logs, Traffic logs, etc.), and / or Known Incidents affecting connectivity (e.g., known ISP outages, Cloud Provider failures, internal SASE / PA issues including underlay connectivity problems, etc.).

[0083] Similarly, as mentioned above, the AAA service can also automatically generate human-consumable and actionable determinations (e.g., summary reports / alerts). The analysis can cover: (1) infrastructure issues (e.g., SASE / PA internal tunnels, nodes, underlay 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 an endpoint agent-based solution commercially available from Palo Alto Networks, Inc., headquartered in Santa Clara, CA, or other commercially available or similarly open-source endpoint agents may be used)), (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 exemplary problems analyzed using the AAA service (608) in several embodiments.

[0085] Referring to Figure 6A, the AAA service 608 is implemented on Kubernetes Cluster 610 as a container service to facilitate scalability (or, for example, another container-based or similar computing environment could be used similarly to implement the AAA service). The AAA service 608 includes components such as the user authentication / traffic analysis component 612, the network access analysis component 614, and the security policy analysis component 616 (for example, the network and security analysis playbook service can accept requests from the AAA service). In an exemplary implementation, Playbooks are implemented as individual modules that perform specific user authentication, network connectivity, and security policy checks (for example, implemented in Python or another high-level programming language). The AAA service 608 is the core service that implements user connectivity checks. The 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, for example, 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, to store traffic logs). The network access analysis component 614 communicates with the Cosmos database 620. The Cosmos database 620 includes a BigQuery database, a Cloud SQL database, and a 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 (for example, an instance(s) of a commercial firewall, such as a Palo Alto Networks (PA) firewall or another commercially available firewall) via an API (for example, the PA Command Framework API) to query the firewall in real time or otherwise (for example, to query firewall operational status information) (102).

[0087] AAA service 608 also communicates with PA AIOPs data service component 602 over the network. Specifically, AAA service 608 communicates with PA AIOPs 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 AIOPs 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 AIOPs services on the Cosmos platform. The AAA service can expose specific endpoints to accept connectivity analysis requests from the UI and 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 service is used to check connectivity between (1) a single user / multiple users / user groups and a SaaS application, (2) a single user / multiple users / user groups and a private application hosted on an on-premises data center or remote branch office, (3) a single user / multiple users / user groups and remote site connectivity (remote branch (RN) or data center (SC)), (4) a site and a network, and (5) a site and another site.

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

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

[0092] In step 632, the data service creates a folder (e.g., a Google Cloud Service (GCS) folder) for each request and creates an entry in the AAA Query BigQuery (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 BQ tables.

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

[0094] In step 634, the Playbook Engine / Authentication Analysis Playbook collects user authentication information. The results are published to a GCS folder and a BQ table, and the playbook status is updated in the BigQuery table.

[0095] In 635, the Playbook Engine / Network Connectivity Analysis uses network service analysis to check network connectivity between the requested source and destination, and can update the determination as shown in 635A and 635B. Network service analysis is performed for the connectivity of network service endpoints (e.g., DNS servers, authentication servers, etc.) and application connectivity (e.g., verifying connectivity between users and applications). Network connectivity analysis uses instance status, tunnel status, instance metrics (e.g., 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 for analysis. The analysis results and playbook status are stored in GCS folders and BQ tables.

[0096] In a typical implementation, the analysis of user-application connectivity utilizes playbooks such as (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, as further described below.

[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:

number

[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:

number

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

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

number

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

[0103] In this exemplary implementation, the AAA service invokes a formal security policy analysis configuration (for example, implemented as a formal security policy analysis library) using the following input parameters:

number

[0104] The formal security analysis function returns the following results:

number

[0105] The AAA service uses the 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 health analysis of applications such as SaaS / private applications), collects unique DNS servers from the test results, and checks or performs the following: (1) the connectivity of the DNS servers from each ingress node (e.g., Mobile Gateway (MU) or Remote Network (RN)) instance, (2) L3 forwarding path tracing of the DNS servers by executing test FIB lookup commands for each unique DNS server IP found in the test results, (3) updating the DNS server connectivity topology based on the L3 forwarding path, and (4) querying each ingress firewall instance to look up the matching rules for each DNS server. The DNS analysis results are returned in the results dictionary under the key "DNS" as follows: For each DNS server, the results include matching rules highlighting which domain names are resolved by a particular DNS server, L3 forwarding results, and security policies (if any) that prevent connectivity to the DNS server.

number

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

number

[0108] In 636, the security policy analysis performs a formal security policy analysis of Network Service Endpoint connectivity and application connectivity, and the determination may be updated as shown in 636A and 636B. The analysis results and playbook status 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 completed.

[0111] III. Security Policy Analysis

[0112] Introduction

[0113] Formal methods are techniques, often supported by tools, for developing software and hardware systems. Given a model of a system (often an abstract model of the system) and a language specifying the desired properties of the system, proofs can be generated to comprehensively verify that the specified properties are met. When the proof is performed substantially by a machine, the verification is called automated (also called "automated inference"). Formal verification is applicable to circuits, protocols, software, and more. As will be described in various ways below, it can also be applied to authorization and / or other security policy-related information / systems such as privileged identity management (PAM) and identity and access management (IAM). By combining a model with a language, it is possible not only to analyze the system but also to optimize it and infer about it. This enables semantic modeling of intents and the construction of computational models of entire security policies (and / or networking configurations), as will be described in more detail below.

[0114] Figure 7 illustrates a security policy and its implementation in different parts of the network. A given security policy can be deployed at multiple points along the stream. Two exemplary methods in which formal validation can be used are control / management plane validation (CPV) and data plane state validation (DPV). Generally, CPV has intent view / specification view / behavior view / instantiation view. An exemplary deployment may be performed in a Secure Access Service Edge (SASE) such as Prisma Access. In an exemplary deployment, each firewall or other appliance provides operational data and core policy information from the management plane (e.g., as a heartbeat every 5 minutes), which helps determine whether the enterprise intent (e.g., to block certain access or allow certain access) is being fulfilled.

[0115] DPVs generally have concrete views / compiled views / structured views / instantiated views. An exemplary deployment runs on a LUT / Security Processing Node (SPN) and uses a pole-and-process architecture. CPVs can answer questions with guarantees about the current and future state of the network. DPVs can typically only answer a subset of questions about the current state of the network. Unlike DPVs, CPVs can provide proactive guarantees before the configuration is pushed / deployed.

[0116] Referring to Figure 7, an example of a potential attack is as follows: A malicious individual might compromise the heating, ventilation, and air conditioning (HVAC) network, gain access to the point-of-sale (POV) network, and then attempt to infiltrate the data center. Formal methods can help determine verifiable whether such an attack is possible. Examples of questions that can be answered using formal methods include:

[0117] * Reachability: Can the Retail Branch (RSB) communicate with the Credit Card Application (CCA)? ASSERT (RSB can communicate with CCA). Is the DNS server globally reachable?

[0118] *Connectivity: ASSERT (RSB can communicate with CCA on TCP port 443).

[0119] *Isolation / Security: Segmentation: Are two subsets, tenants, or application groups isolated from each other with respect to all traffic? Is all communication within a specified boundary secure? ASSERT (RSB can only communicate with CCA on TCP port 443). ASSERT (HVAC network cannot communicate with CCA).

[0120] *Security / Audit / Compliance: Can (or have) unencrypted packets travel between the two branch offices now (within the last 6 months)?

[0121] *Fairness: Does the spine router treat all destinations the same?

[0122] *Robustness: Does any interface failure lead to a loss of connectivity?

[0123] *Reliability: What impact do external events have on internal connectivity?

[0124] Figure 8 shows an example of a simplified security policy. It is written using matching criteria that describe who can communicate with whom, along which ports they can communicate, and what activities are permitted. In this example, we have the HVAC network, the Retail Branch Office (RSB) network, and the Credit Card Application (CCA) from Figure 7, which may have different associated subnets. Let's assume the RSB has subnet 164.1.* and the CCA has subnet 192.1.*. Collectively, across those networks, 2 8 ×2 8 2 8 2 8 There are 1,024 possible server combinations.

[0125] Examining individual rule P2 within the security policy, we find that if the traffic originates from RSB, its destination is either RSB, CCA, or D1 (another specified destination), and the traffic is via port 443, then the traffic should be allowed.

[0126] The firewall is provided with a security policy (e.g., a set of rules P1-P5) as shown in Figure 8, along with clear instructions on how to interpret information such as HVAC / RSB / CCA membership. The rules are applied in order of priority. Therefore, during a session, as the firewall begins to discover information, it looks up the source IP address and determines, for example, which subnet it matches. Assume that an incoming connection has a source IP address that matches a CCA. If the destination is either RSB or CCA, the traffic is allowed (according to rule P3). On the other hand, if the destination is D1, the firewall continues to check the rules until it finds a match. In this case, it matches rule P5, and the traffic is denied.

[0127] The policy shown in Figure 8 can be expressed using Boolean terms as follows:

number

[0128] In this example, the source field can take one of six values ​​(i.e., cardinality is six), and the destination can have one of four values. As a result, the 3D Boolean space is mapped to a 2D Boolean space, and then mapped to a single action (B 3 xB 2 xB 2 →B).

[0129] These sets can be enumerated and translated into if-else-like clauses that describe the firewall's behavior. An example is shown in Figure 9A: Allow if source is equal to HVAC and destination is equal to HVAC or D1. As shown in Figure 9B, this can be represented as a cascading clause in equivalent if-else form and can be compiled (for use with tools such as Verilog). Figures 9C-9D are graph representations of the Boolean coding.

[0130] As will be described in more detail below, a policy analyzer tool (written in a suitable scripting language such as Python in some embodiments) can consume pre-, post-, and default security policies along with various metadata and build models. It can handle addresses and address groups (nested). It can handle applications and application groups (nested). It can handle services and service groups. It can resolve DNS queries. The policy analyzer can be used for a variety of purposes, including continuous post-change analysis and various pre-change simulations. In exemplary implementations, the policy analyzer tool utilizes two components: a front-end normalizer and a back-end solver. The front-end normalizer (also called the normalization layer) consumes behavior / implemented specifications and builds a computational model of the system based on different input formats. Policies are normalized as propositions / propositional formulas. Three examples of sources for front-end normalization include RDS XML, exports from Panorama (e.g., dynamic lists), and exports from firewalls.

[0131] Backend solvers model specifications as predicates (e.g., primary / predicate logic). Hierarchical aggregations of individual policies are expressed in propositional logic. True / false answers are returned as functions of symbolic inputs, and various logical operators are available (e.g., ==>, <==>, ∀, ↑). Various techniques can be used in backend solvers. One example is the CVC4 open-source public domain theorem prover for Satisfaction Modulo Theory (SMT) problems. Another example is the Z3 theorem prover. Backend solvers often rely on domain-specific data structures, which allow algorithms and structured query languages ​​to be layered on top.

[0132] In some embodiments, the policy is written with respect to a string. Exemplary ways of representing various aspects of the policy shown in Figure 8 for use by the SMT solver are as follows:

number

[0133] Automated inference for security policies

[0134] Figure 10 illustrates various examples of potentially problematic security policies. The first policy is overly permissive. Assume Alice is a member of the marketing group and is under investigation (for example, because an administrator has determined that Alice or Alice's account is behaving suspiciously). Policy 21 denies Alice access to the corporate wiki, specifically (which contains confidential internal business information). However, the more permissive policy (10) takes precedence (is evaluated first), and Alice can access the wiki due to her group membership (i.e., Policy 21 does not apply). In the second policy, the scenario is reversed, resulting in an unintended block. Here, Alice's access to a different application (e.g., sfdc) is blocked, even though her access should have been permitted along with the rest of the marketing department as a common marketing tool. The third policy is redundant. Bob is in the engineering group. Bob and members of the engineering group have an explicit rule that allows them access to the wiki. The last policy is missing an enforcement component. In this example, the company or other governance rules / regulations may require DLP inspections to be performed at all times; however, the conditions for such inspections are not set here. Each of these issues (and others) can be detected and mitigated using embodiments of the policy analysis techniques described herein.

[0135] These approaches can help reduce operational costs for both security service providers (e.g., operating security platform 122) and consumers of those services (e.g., enterprise customers such as a single operating network 140). The techniques described herein can enhance troubleshooting through proactive detection and remediation, including reviewing policy and configuration spaces. Policies involved can be security policies, plain network configurations, and / or policies at a highly behavioral abstraction level (e.g., reviewed in an RDS store or state deployed within a firewall). This can be expressed as the following Cartesian product: (Security + Network) × (Policy / Config + State). These approaches can also be used to determine enforcement status (e.g., whether an intent was deployed / realized as expected), and to mitigate change risk (determining the net impact of a major change and identifying whether undiscovered inconsistencies in a proposed change actually increase the attack surface). This approach can also be used in compliance / auditing contexts, enabling automated reasoning about policies and providing strong assurance of accuracy. Furthermore, using these approaches can also be helpful for troubleshooting past issues (for example, how to perform a differential analysis if the configuration three weeks ago seemed correct, but the current configuration has problems). Yet another way in which the approaches described herein can be used is to examine multi-domain / transitional analysis scenarios.

[0136] In some embodiments, system 122 includes a core form engine that supports a structured query language for a complete policy object model. Various exemplary demonstrations described herein can be performed using embodiments of the core form engine.

[0137] Example: Shadowing analysis: Probable vs. Definitive

[0138] Assume that there exists a Policy 100 defined as follows:

number

[0139] This policy stipulates that if traffic is detected originating from user A, B, or C, that traffic should be allowed to pass. However, in this scenario, the logs assume there are zero hits against this policy. One possible reason for this is that one of the policies in the range of 1 to 99 is shadowing Policy 100 (i.e., a higher-level policy is more permissive / expressive than Policy 100, making Policy 100 redundant). An example of a policy that might cause this is as follows:

number

[0140] In the scenario above, Policy 35 targets users A and B, and Policy 47 targets users B and C. Collectively, Policy 35 and Policy 47 target users A, B, and C, meaning that Policy 100 is not triggered.

[0141] A second reason a rule might receive zero hits is that the traffic to date hasn't triggered the policy. This could be because the rule was recently added and / or the traffic is infrequent (for example, it applies to users who rarely log in, or to applications that are rarely used).

[0142] By using formal methods, it is possible to establish verifiable and comprehensively whether Policy 100 is shadowed. If so, a recommendation to delete the policy can be made (for example, by the security platform 122 to the administrator of data appliance 102). Furthermore, it is possible to identify policies that collectively bear the responsibility for shadowing (for example, revealing that Policy 100 is shadowed by a combination of Policy 35 and Policy 47). In this example, all three policies have permit actions (the actions are aligned). However, it is also possible that Policy 35 and Policy 47 have deny actions and Policy 100 is permit (or some other combination). Formal methods can also identify such situations.

[0143] Example: Contra shadowing

[0144] Policies are typically evaluated from top to bottom, with the highest priority rules being examined first. However, in some situations, lower-priority rules may be more permissible.

[0145] Assume the following set of policies exists:

number

[0146] Policy 1 is highly specific to user A. Policy 2 targets users A and B, but since Policy 1 targets user A, Policy 2 will only trigger for user B. Similarly, Policy 3 targets users A, B, and C, but will only trigger for user C. This is a potential case of three progressively coarser policies. The second policy could have been explicitly written for B only, and the third policy could have been explicitly written for C only. Here, there is an intent contradiction, because the first two policies recommend that users A and B be allowed to access the system, while the policy for C is set to deny. A contra-shadowing analysis, which may be performed by an embodiment of security platform 122, can establish that Policy 2 contra-shadows Policy 1 (an intent over-specification), and that Policy 3 contra-shadows Policy 1 and Policy 2 (an intent contradiction). The analysis can be performed on a live system (for example, to make recommendations to administrators and guide them to make any desired changes), or it can be performed non-interactively, offline, or periodically.

[0147] Figure 11 shows an exemplary interface for evaluating firewall security policies. Examples of executable analyses include shadow analysis and contra-shadow analysis. Queries and change management can also be performed. The interface user directs the tool to a directory containing not only security policies but also any other applicable information such as address objects, filters, and service resolution information, which are exported in an appropriate format such as a CSV file. Examples of fields include source zone, source address, source information, profile, source user, destination information, and action. Other fields (e.g., device type, device identifier) ​​may also be included. Such information may be provided manually and / or obtained from execution configurations (e.g., as provided by the execution system or by another tool such as Panorama).

[0148] In the interface shown in Figure 12, the user chooses to load a file and begin running a shadow analysis. The tool then begins building the model, adding each policy in order of priority, and constructing Boolean representations (e.g., IP addresses). In the example shown in Figure 13, when processing Policy 30, it is determined that it is shadowed by Policy 28. In particular, Policy 30 is made redundant in the context of over-specification by Policy 28. A potential reason for this is that Policy 30 was initially implemented using a list of IP addresses. At some point, the list was renamed, and a new list was constructed (and used by Policy 82). The list of destination IP addresses under Policy 28 is a superset of those listed under Policy 30. Other fields are identical (e.g., source zone, application, etc.).

[0149] As the analysis continues, another problem is discovered, as shown in Figure 14. In particular, an intent inconsistency is found. Policy 61 shadows Policy 63, but Policy 61 is a "deny" action while Policy 63 is an "allow" action. There is redundancy in some source addresses, but there is also redundancy in applications. The shadowed policy (Policy 63) has four described applications, while the shadower (Policy 61) applies to "any" applications. One possible reason for this situation is that rule 61 was added during an emergency (e.g., an attack or breach) to quickly block traffic. However, afterwards, the existence of Policy 63 was forgotten, and no cleanup was performed. Such a situation can also occur, for example, if the first administrator enforces rules without documentation. When that administrator leaves, the new administrator may not be aware of the first rule when implementing redundant rules. Since Policy 63 is redundant, it may be recommended to remove Policy 63.

[0150] Another example of a shadowed policy is shown in Figure 15. Notably, Policy 64 enumerates specific IP addresses, all of which are included within the 10.0.0.0 / 8 specification of Policy 25 (i.e., over-specifying intents). Also, the list of applications in Policy 64 is a subset of the applications included in Policy 25. Policy 25 shadows Policy 64. It may be recommended to remove Policy 64. Other recommendations / reports may also be provided. For example, continuous analysis of policies can be performed, and periodic reports can be made regarding any shadowing or other issues. Recommendations can be made to help administrators resolve issues, and tools can be provided where applicable. For example, if a policy is completely shadowed by another policy, it may be recommended to remove the redundant policy (or merge multiple policies into a single policy). As another example, administrators may be presented with the option to change rule priorities (e.g., swap Policy 64 and Policy 25). Administrators can choose to leave the rules as they are, but at the very least, they can make informed decisions to do so. The advantage of continuous monitoring is that when administrators make changes, they can verify that those changes resolved the problem (and did not create or discover new problems).

[0151] Examples: Connectivity analysis and query language

[0152] In addition to identifying instances of shadowing and contra-shadowing in existing policies, another feature offered in various embodiments is the ability to perform queries. One example of query use is performing connectivity analysis (e.g., if existing policies conflict given policy specifications). The following is an example query that could be used to determine how a user accesses Instagram: A query is constructed listing the company's private network (representing 224 addresses) as the source, and Instagram's IP address as the destination. Other information, such as FQDN information, can also be used. The action is allow, the traffic type is any type, and several additional arguments are included (e.g., source zone, destination zone). An APP-ID may be used to specify a particular application or type of application (e.g., "Social Networking"), if necessary. String fields can be regular expressions (e.g., source_user==*alice*). Preprocessing and object / Active Directory / LDAP resolution are performed as needed:

number

[0153] One way to execute a query is by clicking the "Query" button in Figure 16 and entering values ​​into the fields in the query construction region. When the user presses "Submit Query," a query similar to the one shown above is automatically generated and submitted, as shown in Figure 17. Similar to shadow / contra-shadow analysis, the analyzer tool evaluates the provided firewall configuration information (and other applicable information) and builds a model.

[0154] Figure 18 illustrates a partial query inconsistency. Policy 59 enumerates a set of internal servers (e.g., SolarWind servers) whose access is restricted / limited. If a user on any of these enumerated servers attempts to access a destination outside the network of the three enumerated sets within region 1802, that traffic will be blocked. At this point, the administrator can select "block and continue," which allows Instagram traffic as intended, except for the servers to which Policy 59 applies. The query can then be continued to identify any further policies that may be relevant.

[0155] Figure 19 illustrates another partial query inconsistency. In this example, Policy 101 completely blocks a specific group of users with a particular HIP profile from any network access. The administrator can continue the query by clicking "block and continue" again.

[0156] Example: Policy change management

[0157] The aforementioned features, such as shadow analysis and connectivity analysis, can be used in conjunction with a structured query language to evaluate proposed changes as queries against the current policy or in the context of the current policy. Exemplary use cases for policy change management include performing checks before rules are created / updated / deleted, performing checks after rules are created / updated / deleted, and performing "what if" analysis (e.g., trying out a rule before applying it).

[0158] Suppose a new employee (for example, in the marketing department), Nancy Ram, wants to be able to access Instagram from the corporate network. Interface 2000 may be used to determine whether the new policy the administrator is trying to add is redundant (i.e., whether Nancy can already access Instagram without creating a new rule). In the example shown in Figure 20, the administrator is submitting policy parameters to region 2002. One of the parameters is the priority "645" for the proposed new rule. When the administrator clicks "Start Shadow Check," a query like the following may be generated and executed against the current firewall configuration:

number

[0159] Similar to the example shown in Figure 18, this query will partially conflict with Policy 59 (i.e., Nancy will not be able to access Instagram from any of the servers listed in Policy 59). However, Policy 101 will not conflict unless Nancy happens to be a member of the group listed in 1902 and uses one of the listed source HIP profiles.

[0160] As shown in Figure 21, a match with Policy 248 was found. This means that there is no need to insert a new rule to grant Nancy access to Instagram, as Nancy already has access (subject to the constraints of Policy 59).

[0161] Example: Segmentation analysis

[0162] Assume a company has a set of internal Solarwind servers and wants to control traffic between those servers and other internal servers (on the 10.0.0.0 / 8 subnet). The following is an example of a possible query:

number

[0163] In this example, "Solarwinds_servers_alias" is an alias that expands to approximately 400 source IP addresses. The destination is all other servers (10.0.0.0 / 8 excluding the servers within the alias). The purpose of the query is to determine which rules (if any) are associated with such traffic. Assume the following policy is returned:

number

[0164] A partial block means that some traffic is allowed between the Solarwind server and other internal servers. Policies A-D address various low-risk / monitoring activities. Policy E is a catch-all that blocks the rest of the traffic. From an audit or security posture perspective, the objectives behind each of Policies A-D can be justified (i.e., allowing traffic for limited purposes and in limited context), and a "query success" result for Policy E indicates that all other traffic will be blocked. This scenario is also a contra-shadow (also called reverse shadow) scenario in that Policy E blocks everything (after the four previous allowances). However, this is a deliberate policy choice that can be observed during an audit.

[0165] In various embodiments, the security platform 122 includes a repository of invariants that administrators (e.g., of network 140) can modify / extend from current policies, queries, and standards of practice. Invariants may be used to periodically check policies (e.g., every morning at 4 a.m.) to ensure that policy drift is not occurring. Examples of such invariants include blocking all Tor traffic except for members of research groups on research nodes, blocking all WhatsApp file transfers, and preventing guest WiFi in retail stores from accessing the data center. If any of the checks fail, an alert can be generated and a report can be provided.

[0166] Figure 22 is a flowchart illustrating an exemplary process for using security policy analysis in various ways according to various embodiments. Process 2200 (and / or parts thereof) can be executed by various devices / systems. As an example, process 2200 may be executed on / by security platform 122. In this scenario, information such as firewall configuration information, traffic logs, and objects is retrieved from network 140 as needed. As another example, process 2200 may be executed on data appliance 102 or another suitable node within network 140 (e.g., a management console / server configured to manage data appliance 102). In this scenario, the information necessary to provide policy analysis remains within network 140. As a third example, security platform 122 and one or more nodes within network 140 work together (e.g., depending on the scope / type of analysis performed, analysis is performed on security platform 122, within network 140, or both).

[0167] In 2202, configuration information is received. As described above, examples of such configurations include security rules / policies (e.g., those extracted live from a running firewall, copies of historical configuration information, etc.) and other configuration information (e.g., address objects, filters, service resolution information, Active Directory information, LDAP information, etc.). In 2204, a model is built using the received configuration information. As described above, an exemplary method for building the model is to use the SMT solver. In 2206, a policy analysis is performed using the model. Various types of analysis have been described above (e.g., shadow analysis, contra-shadow analysis, before-and-after management analysis, query analysis, on-demand policy simulation, sandbox analysis, etc.), and additional information regarding performing various types of analysis is described throughout this specification. Finally, in 2208, the results of the policy analysis are provided. An example of such results is shown in Figure 13 (e.g., identifying intent over-specification). Other examples of results (e.g., on-demand reports, periodic reports, etc.) are described throughout this specification, as are examples of recommendations that can be made based on those results.

[0168] IV. Security Policy Analysis Use Case Scenarios

[0169] Introduction

[0170] Enterprise customers deploy firewalls to protect their network infrastructure and applications. They specify firewall security policies that determine which traffic is allowed and which is not. An exemplary firewall policy includes multiple rules. Typically, customers provide different rules based on the type of traffic. In the following explanation, we assume the enterprise is the apparel brand "ACME Clothes". One exemplary policy allows fashion designers to access applications intended for apparel design. Another exemplary policy prevents those fashion designers from accessing financial documents or data center resources. Enterprises explicitly provide rules that allow / deny access to various sources and destinations. Sources / destinations can be specified by network identifiers (e.g., source and destination IP subnets). Sources / destinations can also be specified using groups or other dynamic identifiers (e.g., members of the fashion designer group versus members of the finance department, Windows 10 computers, BYOD (bring-your-own-device) devices, etc.).

[0171] One common problem is that over time, companies can end up with hundreds or even thousands of rules in their security policies, and rules can accumulate, especially as network administrators join and leave the company. A considerable number of outdated rules can be built, some of which may provide broad access beyond what is needed or desired, but there is no efficient way to identify such rules. Some rules are redundant. As an example, suppose Becky is a fashion designer at ACME. While there may be a rule that allows members of the fashion designer group to access apparel-related applications, the security policy may also have a rule that explicitly allows Becky to access those applications. One reason for this might be that Becky joined the company in its early stages, before a clear fashion designer group existed. Later, when rules that applied to all fashion designers were added, no cleanup was done to remove the individual items for Becky. In a related example, Becky changes her role from fashion designer to sales. Becky's group membership will change, but the remaining rule allows her to continue having access to the apparel application, even though it may be inappropriate for her new role. As another example, suppose Becky remains a member of the fashion design team and is promoted to a management position. In this case, Becky may be a member of both the fashion designer group and the management group. There may be two conflicting rules governing Becky's access to confidential financial information. There may be one rule blocking fashion designers from accessing the financial server / application, and another rule allowing managers such access.In such a scenario, what is the intent? Should Becky be allowed access to the financial server / application? The various approaches described throughout this specification involve performing automated, verifiable analysis against policies to help organizations ensure their policies are up-to-date, appropriate, and free from conflicting intents.

[0172] For any rule change (adding rules, deleting rules, changing rule priorities, etc.), there is a specific point in time when the change occurs. For that change, there is a "pre-world" environment, which can be used to model / simulate the policy change before it is rolled out to the production environment, helping to determine whether the change will cause problems. This is also called "shifting left." Despite various tools, bugs are inevitable (e.g., due to human error). Furthermore, because enterprise networks are dynamic environments, rules / policies that previously worked as expected may now be causing problems (e.g., a member of one department moves to another, but the group membership is not updated accordingly). "Shifting right" can help address these situations. After the policy is rolled out, ongoing monitoring and analysis of the policy can help detect problems.

[0173] Use Case: Shift Right - Formal Modeling-Based Analysis (Continuous Analysis After Changes)

[0174] Suppose an unintended change occurs to ACME's security policy posture. This change may be due to human error or a change in the environment. Continuous monitoring / policy analysis may be performed, for example, each time a change is pushed, or iteratively (e.g., once every 24 hours). In an exemplary embodiment, a tool such as Prisma Access can be used to collect information from all firewalls (or other data appliances) deployed by the enterprise (i.e., a collection of firewalls). Policies are analyzed for errors (e.g., using the techniques described herein). For each error detected (also called a policy anomaly), an incident may be generated. Where applicable, additional contextual information may also be provided, such as the amount of traffic associated with the anomaly rule or set of rules. An example of an anomaly is a policy with priority 10 whose intent is fully covered by a policy with priority 5 (e.g., a rule allowing a fashion designer to access a resource at location 5, and a rule allowing Alice (who is a fashion designer) to access the same resource at location 10). Another example of an anomaly is a pair of conflicting policies (e.g., both allowing and denying Alice access to a specific resource). For example, an incident can be automatically generated that provides a name for the anomaly type, shows both rules, shows the traffic hitting such rules, and enumerates the users / groups involved, the address objects involved, etc. The incident can be integrated into a ticketing system so that the appropriate members, such as the security operations center, network operations center, and IT support, can investigate the incident and attempt to resolve the issue. One example of how to resolve the issue is to identify, for example, that rule 10 is redundant with respect to rule 5 and should be removed.Administrators can make changes manually (for example, by deleting rule 10) or they can automate changes using guided tools (for example, by clicking on a suggested action to delete the rule). Once changes are made, the ticket may be updated to "resolved" after, for example, an operator confirms that the changes have successfully resolved the issue.

[0175] Another type of anomaly is a hit count anomaly. In this scenario, no specific rule is used, and there is no traffic matching the rule over a long period (e.g., 30, 60, or 120 days of traffic). In this case, the rule can also be flagged as an anomaly / incident generated for operator investigation.

[0176] Use Case: Shift Left - On-Demand Policy Simulation (New Rule Intent Satisfaction Analysis)

[0177] Assume a policy exists for users at an ACME branch. This policy includes a rule stating that fashion designers should have access to the apparel design application. When a new employee, Hank, is hired for the position, part of the new hiring checklist followed by the IT department includes granting Hank access to the application. The operator responsible for granting access may not be aware that a rule already exists granting access to members of the fashion design group. So, instead, the operator creates a new rule that explicitly grants Hank access. As additional employees join, the operator continues to add rules granting individual access to each additional employee (continuing to be unaware that group-applicable rules already exist). In another example, suppose an employee, Ed, states that he needs access to a sensitive application (e.g., a financial application). Ed is a member of the engineering team. The IT operator assigned to Ed's request reviews the request, determines it is legitimate, and adds a rule granting Ed access to the application. As in the previous scenario, assume the operator is unaware that an existing rule exists blocking engineering team members from accessing the financial application. Here, intents conflict.

[0178] Through continuous monitoring, such issues (e.g., newly created duplicate rules and / or newly created conflicting rules) can be detected as anomalies (e.g., within 24 hours), and incidents / tickets can be opened to correct them. An alternative approach to addressing these types of situations is for operators to use the "New Intent Analysis" feature (e.g., provided within the interface by security platform 122). By using this tool, operators can identify mistakes before they occur, before committing new rules to production. Using the tool, operators propose a change (e.g., explicitly granting access to Hank as new Policy 202). The system then evaluates the policy using the modeling / analysis techniques described herein to determine if the proposed change is redundant (i.e., access is already permitted by an existing policy). If so, the system responds that the rule is not needed and provides a reason (e.g., Hank is already granted access by rule 33). The report may also indicate that the proposed rule conflicts with existing rules. As an example, suppose there is a rule that grants fashion designers access (Rule 33) and simultaneously a rule that denies new hires access (Rule 20). The operator can conduct further investigation before deciding whether or not to grant Hank access (due to the apparent conflict). For example, the rule denying new hires access may be implemented at the request of the legal department to ensure that all new hire documents are received / signed before access to any system (or various systems / applications) is permitted. In this scenario, the conflict is intentional and serves a purpose.Alternatively, the inconsistency could be an error (for example, the rule priority might be incorrect, and a rule granting access to fashion designers should have a higher priority than a rule blocking access for new hires). In any case, operators can be warned that inserting a rule against Hank (without further investigation) might be undesirable.

[0179] Use Case: Shift Left - On-Demand Policy Simulation (Production Environment Anomaly Policy Analysis and Hit Count Analysis)

[0180] One approach to keeping security policies up-to-date and accurate is to perform continuous / periodic analysis automatically. In an exemplary implementation, whenever a change is committed and / or at periodic intervals (e.g., every 6, 12, or 24 hours), the production environment policy may be retrieved, analyzed, and any detected anomalies automatically inserted into the ticketing system.

[0181] Some companies (e.g., international banks) prefer to rely on a dedicated team of security policy analysts to handle policy management / auditing. Instead of continuous monitoring, that team evaluates policies every three or six months (i.e., as often as they use when evaluating security policies). Between evaluations, a large number of outdated, redundant, conflicting, or otherwise problematic rules may be created.

[0182] Suppose a company has a set of policies for its branches (e.g., individual bank branches) and another set of policies for mobile users (e.g., employees working from home or frequently traveling). Each policy has a set of associated rules. One feature provided by the embodiment of security platform 122 is the ability to perform on-demand batch analysis of policies (e.g., against historical information). As an example, a security policy team could run a report determining which policies had zero hit counts over the past three months, which policies had conflicts, etc. Instead of creating individual incidents to be addressed by operators (e.g., through integration with a ticketing system), the security policy team could use the information contained in the report to determine what action should be taken (e.g., make changes to production policies or ignore specific identified issues). After changes have been made, the security policy team could rerun the on-demand analysis to determine whether they succeeded in resolving the issues they were trying to resolve (and whether new issues arose as a result of those changes).

[0183] Use Case: Shift Left - On-Demand Policy Simulation (Security Policy Sandbox Anomaly Analysis)

[0184] Assume an administrator instantiates a sandbox on Monday using branch user policies. Over the course of a week, the administrator makes various changes to the sandboxed policies (e.g., allowing different branches to access different resources based on jurisdiction, such as a GDPR-compliant version for European branches). Before pushing the sandbox changes to production, the administrator wants to ensure that the sandbox changes do not create any new anomalies (e.g., no redundancy, no conflicts, etc.). In various embodiments, security platform 122 provides the operator with the ability to perform policy anomaly analysis on the sandbox (e.g., by providing sandbox identification and requesting analysis). Once the analysis is complete, the operator is provided with a report of the anomalies identified in the sandbox. The operator can then make further changes in the sandbox and run the analysis again to see if the identified anomalies are now resolved (and / or if the fixes have brought new problems to the surface or caused them). The operator can repeatedly request analysis and make adjustments until they are satisfied with the sandboxed policy, and once satisfied, the operator can push the policy to production during an appropriate change window.

[0185] Use Case: Shift Left - On-Demand Policy Simulation (Resolving Security Policy Anomaly Incidents Using Sandbox)

[0186] If an anomaly is detected in the production environment (for example, through the ongoing post-change analysis described above), one option is for the incident to be resolved directly in the production environment. For example, if a decision is made (for example, as part of a night job) that a redundant rule has been added to the production system, an incident may be created and automatically added to the ticketing system for operator resolution (for example, it may be assigned an incident ID number such as incident #10382). After reviewing the information, the operator may choose to remove the redundant rule during the change window (for example, based on the suggested recommendations provided by the policy analysis system or based on the operator's own judgment). If the operator is lucky, the change may fix the problem (for example, this will be confirmed during the next designated policy analysis). Unfortunately, the operator may not always be lucky. Instead of removing the redundant rule, the operator may enter the rule number incorrectly and delete an adjacent rule. Here, the production system has two problems: the initially identified redundant rule (i.e., the anomaly identified as incident #10382) remains, and a rule that should not have been deleted was deleted in the production environment.

[0187] If changes made in the production environment do not fix the problem (and potentially create a new one), the cost can be significant. An alternative approach is for the operator to create a sandbox (using production environment rules) and make the changes(s) that the operator believes will address the identified anomalies. The operator can then submit a sandbox policy for analysis (e.g., using the incident resolution analysis capabilities provided by security platform 122). In an exemplary embodiment, the operator provides the sandbox identification and a list of incidents(s) (e.g., incident #10382) that the operator believes will be resolved. Security platform 122 performs a policy analysis on the sandbox and generates a report (e.g., indicating whether incident #10382 and / or any other enumerated incidents were resolved by the changes made in the sandbox, whether any problems(s) remain, and / or whether new incidents were detected, as well as the reasons for the decision). The operator can iterate (make changes in the sandbox and rerun the incident resolution analysis) until they are satisfied. Once satisfied, the operator can push the sandbox changes to the production environment.

[0188] Use case: User group normalization and formal modeling

[0189] As mentioned above, when building a formal model, various pieces of information are used as input, including security policies and other information (e.g., address objects, filters, etc.). Rules can generally be thought of as having one of two types. The first type is network-style rules, which enumerate source / destination information using network configurations such as IP addresses and subnets. The second type uses information such as user / device information and application information. Unfortunately, building a model using the second type of information can be difficult. Suppose the first rule specifies that employees are allowed to access the fashion design application. The second rule specifies that fashion designers are allowed to access the fashion design application. The third rule specifies that new hires are not allowed to access the fashion design application. Each of these rules is a group-based rule. In this scenario, there are three user groups: employees, fashion designers, and new hires. How can security platform 122 determine redundancy across these three rules? The source column of the first rule contains the string "employees". The source column for the second rule contains a different string, "fashion-designers". The source column for the third rule contains the string, "new-hires". Simply comparing the three source values, it appears there is no redundancy because the strings are different. However, examining only the string values ​​is insufficient to identify redundancy. Instead, each group needs to be broken down into a normalized list of its respective memberships. Similarly, individual users can be included in the rules in various ways (e.g., email address, Active Directory name, wildcards such as "FirstName=Jeff, LastName=*"). These names also need to be normalized / standardized. An exemplary approach is as follows:

[0190] First, each individually specified user is normalized. Second, groups are broken down into user lists (which are also normalized). Third, overlaps between groups are determined. Finally, the normalized names and any identified overlaps can be used as appropriate to construct the model.

[0191] Use case: Policy Sandbox (multiple Sandboxes per operator with editing, production environment refresh, annotation, and push-to-production)

[0192] The following explanation assumes a retail company (e.g., a home improvement store chain) wants to deploy a new application suite for use by employees in its retail stores, providing functionality such as inventory tracking, attendance management, and returns processing. Instead of deploying the new application suite company-wide (e.g., across 3,000 stores), a handful of stores in various locations are selected for a pilot (e.g., 10 stores on the West Coast, 10 on the East Coast, 10 in Canada, etc.).

[0193] The corporate IT department wants to know how the application suite is performing (e.g., whether sales are improving, whether employees are adopting the tools provided by the suite). One task the corporate IT department will perform as part of the project is to specify a limited set of branches (i.e., branches in the pilots) that should be allowed access to the application suite. One approach the corporate IT department might adopt is to define a “pilot” group containing various pilot branches and grant access to the new application to the networks / devices in those branches. The corporate IT department could also explicitly block access to the suite for the other 2,970 branches. Adding these rules can be particularly complex, for example, determining where (i.e., in what priority order) the new allow / block rules should be inserted within existing corporate policies (which may contain hundreds or more rules). Various anomalies can occur, especially considering the complexity that may be involved in conducting the pilots.

[0194] In various embodiments, the security platform 122 provides a policy sandbox function. This function allows an operator authorized to update security policies (e.g., within the IT department) to request the security platform 122 to create a policy sandbox (e.g., instantiated using a copy of the branch security policy currently running in the production environment) or multiple policy sandboxes (e.g., one for branch policies and one for mobile policies). The operator can then modify policies, add new rules, and / or move / delete / edit existing rules within the sandboxes. Furthermore, multiple operators can each access a sandbox (as a shared resource such as a team sandbox) or have access to individual sandboxes (e.g., two operators each have three sandboxes).

[0195] Assume that an operator engaged in a branch pilot makes various changes in a sandbox and is ready to push the changes to the production environment. The operator requests and obtains approval for a change ticket (for example, between 1 a.m. and 3 a.m. on a Sunday). One situation that may arise is that other modifications are made to the production environment security policy in the time between when the operator is satisfied with the sandbox version of the branch policy and the change window. For example, another operator may modify the production environment security policy in the middle of the night. Since the sandbox was instantiated based on the production environment that existed at the time of the instantiation request, those production environment changes do not exist in the sandbox. If the operator proceeds to push the sandbox version of the policy to production during the change window, one thing that may happen is that the production environment changes made in the middle of the night are overridden. In some embodiments, the security platform 122 provides protection against this scenario. When the operator is ready to push the changes made in the sandbox to production, the operator can request that the underlying instantiation be refreshed (i.e., that the changes made in the middle of the night are refreshed in the sandbox). Changes made by operators within a sandbox after its initial instantiation can be replicated to a refreshed sandbox. Four exemplary scenarios are possible. First, new rules that did not exist in the original sandbox instantiation may have been added to the production environment. These new rules are added to the sandbox. Second, rules that existed in the production environment at the time of sandbox instantiation may have been deleted. These rules are also deleted from the sandbox. Third, rules that existed in the production environment at the time of sandbox instantiation have been modified, but these changes do not affect changes made in the sandbox. The rule is updated in the sandbox. The last scenario is the most complex, where a rule is modified in the production environment and also modified in the sandbox.Here, a conflicting version of the rule exists.

[0196] In various embodiments, when an operator refreshes the sandbox, the differences between the current production version and the sandbox version are highlighted, showing, for example, which rules have been added, deleted, updated, and which rules represent conflicts. For any conflicts, the operator can decide which version of the rule to use, i.e., whether to use the production version or the sandbox version. Once the operator is satisfied with the sandbox version, they can push the sandbox version to the production environment.

[0197] V. Appendix

[0198] The following sections provide additional details regarding exemplary implementations / embodiments of the policy analysis techniques described herein.

[0199] Operational use cases 1. Business disruption - A policy fails to grant access that should be permitted, resulting in the issuance of an operation ticket to resolve the access issue. 2. Security Issues - Policies are overly permissive, allowing access that should be blocked. The majority of data breaches are based on permissive policies, and when policies are overly permissive, breaches can access even more data than would be possible with proper policies. 3. Policy sprawl - The intent of a rule is encompassed by another, broader rule or set of rules. 4. Customers try to strengthen their systems by adding detailed policies, but forget to remove coarser ones. 5. When customers try to organize their policies, they combine several detailed policies into broader ones and forget to delete the detailed policies. 6. The customer was satisfied with the intent of the new business. a. We decided to add a new policy, but we didn't realize that this would make other policies redundant. b. The customer's new policy is already being shadowed by a higher-level, coarser policy. c. The customer's new policy is already covered by a lower-level policy, making the customer's new policy redundant (reverse shadowing). 7. Policy Drift a. The customer intends to make policy changes, but will create a copy of the policy to keep as a backup and move it down the list. b. The customer makes the changes, takes time, and tests the new copy (at a higher level). Meanwhile, other operators are adding new policies between them.

[0200] Exemplary alert / incident list 1. Alert / Incident Name Format

[0201] Alerts are prefixed with a single adjective, one of the following: "REDUNDANT," "SHADOWED," "REDUNDANT," "GENERALIZED," or "CORELATED."

[0202] The grammar is as follows: Security Analysis Alert / Incident Code Format Code: AL_<INDUSTRY TERM_ADJECTIVE> _<POLICY1_ACTION> _<POLICY_TYPE> _COVERED_BY_<HIGHER|LOWER> _ORDER_<POLICY2_ACTION> _RULE Example code: "AL_REDUNDANT_ALLOW_SECURITY_RULE_COVERED_BY_HIGHER_ORDER_ALLOW_RULE" display name:"<INDUSTRY_TERM_ADJECTIVE> Policy:<POLICY1_ACTION><POLICY_TYPE> is covered by<higher|lower> order<POLICY2_ACTION><POLICY_TYPE> " Example display name: "Redundant Policy: Allow security rules are covered by higher-level allow security rules" INDUSTRY_TERM_ADJECTIVE:"Redundant","Shadowed","Generalized","Correlated" POLICY_TYPE: "Security Rule", "Decryption Rule", "Authentication Rule", "Application Override Rule", "DLP Rule", "URL Filtering Rule", etc. POLICY1_ACTION, POLICY2_ACTION: These are policy type specific. Security Rule actions are either "Allow" or "Block". The Decryption Policy action is either "Decrypt" or "No Decrypt".

[0203] Exemplary alert / incident list with code / display name

[0204] Examples are shown in Figures 23A to 23C.

[0205] Formal modeling-based services

[0206] Formal methods are an approach for comprehensively and provably modeling, analyzing, and optimizing the behavior of hardware and software systems. When applied to policy / configuration modeling / analysis / optimization in areas such as security, networking, and modern identity and access management (IAM), formal methods enable semantic modeling to realize a functionally accurate “model of computation” of the system's intent / behaviors.

[0207] Core Formal Modeling Library

[0208] Embodiments of the Core Formal Modeling Library accept the following. 1. Security policy specifications (e.g., user / customer intent) for different device groups (MU, RN, GW, SC), as well as 2. Data for resolving all internal (objects, lists, etc.) and external (runtime firewall data, LDAP / AD data, predefined data, etc.) dependencies within the security policy specification.

[0209] Using this data, a single unified logical computational model for the firewall's security policy is constructed, which is also referred to herein as the formal model. This formal model forms the basis for supporting multiple analysis and security regime evaluation use cases within the AIOps platform, including but not limited to shadowing / conflict analysis, policy change management, and application access analysis.

[0210] The core format modeling library constructs a comprehensive logical computational model using the CVC4 library, for example, with Security Policy, Firewall Configuration, and firewall operational status (such as FQDN files, external dynamic lists, etc.) collected by the Artificial Intelligence for IT Operations (AIOps) platform of Prisma Access. CVC4 is an automatic theorem prover for satisfiability modulo theory (SMT) problems. The formal model uses a mix of boolean, integer, enumeration, string-to-enumeration, and character representations to resolve / flatten / normalize the security model by resolving all internal and external object dependencies.

[0211] As an example, the library supports the following three use cases, each of which can be realized as a stand-alone service or a set of services in the Prisma Access AIOps platform. 1. Shadowing / conflict analysis 2. Policy change management 3. Security policy query / analysis within the application access analyzer

[0212] To perform the following, for example, microservices are built on top of Google Kubernetes Engine (GKE). 1. Extract the JSON configuration from Google Cloud Storage (GCS) (e.g., triggered via a configuration parser service or a periodic trigger service), 2. Use the firewall data fetch library (lib) to extract firewall command output, 3. Invoke the core format modeling library for the above use cases.

[0213] Exemplary input 1. Configuration parser service (XMLtoJSON) security policy from microservice. In an exemplary embodiment, this is an unresolved JSON, i.e., the security policy may refer to symbolic addresses, address lists, services, service lists, etc. The JSON holds / embeds additional information via a dictionary of key-value pairs, where the keys are symbolic addresses, address lists, etc., referenced within the security policy, and the values ​​are the necessary information available to fully resolve the security policy for formal modeling purposes. 2. Firewall operating status A.FQDN file B. External Dynamic Lists C. Predefined object information extracted from XML found within the firewall. D. Extensive user-to-group mapping information (required for formal modeling of complete fidelity of security policies) E. Comprehensive user-to-persona mapping information (required for full-fidelity formal modeling of security policies) F. One-time on-demand user-to-group mapping information (to support application access queries) G. One-time, on-demand user-to-persona mapping information (to support application access queries)

[0214] Call / Operation Mode 1. Formal modeling can be triggered as a result of committing a new security policy. 2. Formal modeling can be triggered as a predetermined / periodic refresh when only operational data from the firewall is used to refresh the formal model. 3. Formal modeling may be requested as part of a policy change management workflow via the AIOps data service API.

[0215] output 1. Security policies fully resolved, with some exceptions. 2. Exceptions that occur during modeling due to incomplete or malformed data. A. Security policy issues such as cut-and-paste or formatting errors, or references to objects or lists that have not yet been defined. B. Operational state data issues such as missing FQDN entries or incomplete address objects. 3. Parsed firewall operational state persisted in a structured format. 4. A fully resolved formal model of security policies, with some exceptions.

[0216] Shadowing / Contradiction Analysis

[0217] One objective of formal modeling-based shadowing and contradictory shadowing analysis is to flag over-specified or contradictory redundancy within intents to identify root causes, reduce policy / permission / privilege sprawl, and fix potential security holes / vulnerabilities. Redundancy can be one (or a set) of higher-priority policies, and root cause identification involves forward as well as backward traversal to identify shadowing, generalization, and partial conflicts through interactive model building and blocking frameworks, or frameworks that generate incidents using incident generation frameworks for ultimate consumption by users / customers (as implemented in AIOps).

[0218] input 1. A fully resolved security policy JSON with an embedded policy model.

[0219] Call / operation mode 1. This is executed inline during the construction of the security policy format model as a result of committing a new security policy. 2. Triggered as a result of changes in firewall operating status (the frequency and list of changes that can trigger this analysis should be determined). 3. Can be required as part of the policy change management workflow as part of three use cases. A. Shadow / conflict / hit count analysis. B. Incident resolution analysis. C. Shadow / conflict security policy analysis.

[0220] Output 1. A list of shadowee - shadower objects, one for each principal (shadowee). Each shadower and shadowee (or multiple shadowees) contains raw (unsolved) information and fully resolved information necessary for UI display. Depending on the call mode of this analysis, the caller processes the output and transfers it to either the alert / incident engine or the UI. 2. Alert / incident codes are input for each shadowee - shadower object and, when the results are transferred to the alert / incident engine, become one of the 16 described in the security policy incident document above.

[0221] Exemplary architecture for shadow / conflict analysis

[0222] Figure 24A shows an exemplary architecture for evaluating config commits.

[0223] Figure 24B shows an exemplary architecture for performing periodic analysis. In one example, since the firewall related to DNS proxy / EDL / group - to - user / pre - defined mapping can change without config changes, shadow / conflict analysis is performed periodically.

[0224] Figure 24C shows an exemplary architecture for performing analysis against the currently committed security policy.

[0225] Figure 24D shows an exemplary architecture for performing analysis on uploaded security policies to capture proposed changes to the security policy.

[0226] Policy Change Management

[0227] Formal modeling can be used in conjunction with structured query languages ​​to represent policy configurations (fields within these structures can be fully or partially specified, and the fields themselves can also be partially or fully specified). For example, a simple query can support a set / list of source IP addresses and Boolean operations on such sets (e.g., connectivity can be queryed against a set obtained by subtracting ['10.0.1.24', '10.4.55.4', ...] from 10.0.0.0 / 8). This exposes a powerful interface that enables various use cases such as policy change management (e.g., sandbox testing and validation of proposed changes before final commit) and connectivity analysis (e.g., which users / subnets can access which applications / servers / services / resources).

[0228] The following are five example workflows that can be supported under policy change management: 1. Regarding currently committed security policies: A. Intent satisfaction analysis. B. Shadow / Contradiction / Hit Count Analysis. 2. For uploaded security policies that capture all proposed changes to the security policy: A. Incident resolution analysis. B. Shadow / Conflicting Security Policy Analysis. C. Application access queries.

[0229] Policy change management for currently committed security policies

[0230] In the intent satisfaction analysis workflow, user input is XML containing the proposed policy additions. For each new policy captured in this uploaded XML, the analyzer reports whether the intent is unfulfilled, partially fulfilled, fully fulfilled, or blocked, and provides a corresponding list of security policy matches. The reference security policy model used to perform this analysis is, in various embodiments, a formal model of the currently deployed security policies.

[0231] The Shadow / Inconsistency / Hit Count Analysis workflow uses the reference security policy model of the currently deployed security policies as the reference model for performing the analysis. It returns a comprehensive analysis of all shadows and inconsistencies (regardless of dashboards / configuration preferences / customizations suppressing specific alerts / incidents). The Hit Count Analysis extracts and aggregates the hit count for each security policy currently deployed from all production firewalls for a specified device group. This reports rules that have not had a hit since the last successful commit (with certain limitations / assumptions described in more detail below).

[0232] Policy change management for uploaded security policies to capture proposed changes to security policies.

[0233] In the workflow under this category, users model proposed changes to security policies (for example, in Panorama), export the XML of the proposed configuration, and this is then uploaded as part of each use case (three of which are listed below). The Config Parser service is used to build a fully resolved policy model of this XML using information (behavioral data) extracted from the latest fully resolved policy model of the device group. 1. In the incident resolution analysis workflow, the user provides one or more incidents that are queried against a newly constructed format model for the security policy XML uploaded by the user. For each incident, a shadow / inconsistency analysis is performed to determine whether the proposed changes in the uploaded policy XML resolve the incident. A complete list of incidents generated based on the last analysis run is retrieved from alerts maintained and tracked by the policy change management microservice. 2. Shadow / inconsistent security policy analysis uses a format model of the security policy XML uploaded with the request, and the results are returned for consumption via the UI. 3. Application access queries use the newly constructed security policy model to answer eligible queries that have the structure (for example) "Can user X access application Y?".

[0234] Workflow for policy change management

[0235] Figure 25 shows an exemplary workflow for policy change management.

[0236] Example data service (API) for policy change management

[0237] In various embodiments, the data service provides an API interface (for example, using the Quarkus Framework) for triggering policy change management. In some embodiments, the UI interface is provided through the following exemplary endpoints: [Table 1]

[0238] Application Access Analyzer Security Policy Query / Analysis

[0239] Figure 26 shows an exemplary architecture.

[0240] input

[0241] A query that is either a fully specified security policy JSON or a partially specified security policy JSON.

[0242] Call / Operation Mode 1. Upon receiving a query, the formal query microservice retrieves the last fully resolved policy JSON containing an embedded formal model for the security policy. 2. The firewall command data fetch library is used to retrieve user-to-group and user persona information using the following commands: A.show user user-attributes user <username> B.show user user-ids match-user <username> 3. The query is extended to ensure that the connectivity satisfaction check includes the results of the fetched firewall data.

[0243] output

[0244] The output provides a list of policy objects that semantically match the received query. For each matching policy object, if applicable, raw (unresolved) and fully resolved information required for UI display is provided.

[0245] Description (Core-format modeling microservices)

[0246] Microservices are provided for formal modeling-based services and can invoke other libraries, such as a config parser library, a firewall data fetch library, or a formal modeling core library, based on event type and parameters. These libraries can be invoked directly or as separate threads, as needed. The microservices monitor the output of the libraries, update their status, and put the final result into GCS. This triggers / clears alerts via the incident generation workflow.

[0247] Config parser library

[0248] XML is provided for analysis in various policy change use cases. As an example, the config parser library is used to convert XML to JSON. The config parser library defines classes for converting the provided XML (in file or text format) to JSON based on the provided schema.

[0249] Firewall data fetch library

[0250] The firewall data fetch library uses the command framework library, which in turn invokes the firewall (e.g., PA) command framework to obtain firewall output. The firewall data fetch library can store the output in GCS, which can convert XML / text to JSON based on the provided schema. The firewall data fetch library can be used for periodic data retrieval from the firewall.

[0251] Examples of supported commands

number

[0252] Exemplary output

[0253] GCS

[0254] The illustrative output includes the formal modeling output and the fully resolved config JSON, as well as the shadow / inconsistency policies resulting from the analysis.

[0255] Incident generation / organization

[0256] An incident arises for any shadows / inconsistencies found during the analysis. A comparison is also made with open alerts for these tenants, and alerts that no longer exist are cleared by sending a message with the alert status as cleared in the incident generation workflow. Current open incidents can be extracted from GCS.

[0257] Example format

number

[0258] Security change pre / post analysis

[0259] Security and networking teams face several challenges in maintaining policy sets. Here are some examples:

[0260] All security policy rules within an enterprise require careful management to ensure the right balance between a rigorous security and compliance system and the necessary application connectivity and performance. A large number of rules means increased operational overhead in managing them.

[0261] Policy sprawl inevitably occurs, and policies become increasingly bloated. This makes policy analysis extremely difficult in the event of connectivity failures or breaches. One example is "policy sprawl and drift," where new policies are added to allow new applications / users / network connectivity or to segment / deny existing allowed connections as business and security needs change. However, sometimes existing policies are sufficient to accommodate this intent or edit. However, in most cases, it is difficult for operators to analyze hundreds or thousands of policies to understand whether policies actually need to be added or removed.

[0262] Security / network teams undertake periodic policy reorganization, but knowing what can be reorganized is not always easy. Business intents change, and policies become redundant. Alternatively, some policy intents may be covered by one or more other policies (shadowing). Operators need to ensure that the policy posture remains unchanged regarding permitted connectivity or required segmentation before reorganizing policies.

[0263] Another scenario involves mitigating change risks when fulfilling new business intents. When fulfilling intents for new connectivity or segmentation, operators want to ensure they do not compromise previous intents. Operators need a way to analyze the overall extension of connectivity or segmentation from previous policies and ensure it remains limited to what its intent was.

[0264] Another situation involves mitigating the risk of change in terms of maintaining regulatory compliance and meeting critical business connectivity requirements. To ensure successful audits and avoid regulatory penalties, IT / Infosec officers and legal / finance departments want to ensure that crown jewel segmentation remains maintained after policy changes are made. Certain application connectivity is essential for the business to function. IT / Infosec officers and business unit officers also want to ensure that it remains intact, as any breach would hinder business revenue and employee productivity. Regarding permitted connectivity, operators want to ensure that their networking and security operator teams are only allowing limited amounts of traffic (e.g., ports 443 and 8080 or web only). Operators need a way to provide rules for defining the required segmentation and connectivity crown jewel requirements.

[0265] Exemplary Workflow

[0266] Figure 27A shows the new policy addition workflow.

[0267] Figure 27B shows a workflow for periodic policy refinement, including optimization and hardening.

[0268] Figure 27C illustrates a workflow for implementing complex new policy changes (e.g., for application rollouts or other business / security needs).

[0269] Figure 27D illustrates policy incident resolution (for example, to identify errors).

[0270] Exemplary dog ​​case [Table 2] [Table 2-1] [Table 2-2] [Table 2-3] [Table 2-4]

[0271] Exemplary user elements used in various embodiments [Table 3] [Table 3-1] [Table 3-2] [Table 3-3] [Table 3-4]

[0272] Exemplary initial analysis tools, inputs, and outputs used in various embodiments. [Table 4] [Table 4-1]

[0273] Exemplary report format used in various embodiments

[0274] In the following example, we assume that "Tom" belongs to "group-barbara" and "Marie" belongs to "group-satish". Exemplary policy layer options include (1) Prisma Access Shared Pre-Rule, (2) Prisma Access Shared Post-Rule, (3) Mobile Users Pre-Rule, (4) Mobile Users Post-Rule, (5) Remote Workforce, (6) Explicit Proxy, and (7) Remote Networks. Various exemplary report formats (and / or excerpts thereof) are provided below. Examples of security policy selections include (1) Mobile Users Remote Workforce (GlobalProtect), (2) Mobile Users Explicit Proxy, and (3) Remote Networks. New Rule Intent Satisfaction Analysis (New Rule Allowing Action) - Report [Table 5] [Table 5-1] [Table 5-2] [Table 5-3] New Rule Intent Satisfaction Analysis (New Rules with Rejection Actions) - Report Excerpt [Table 6] [Table 6-1] [Table 6-2] [Table 6-3] [Table 6-4] Security Policy Anomaly (BPA) Hit Count Analysis - Report [Table 7] [Table 7-1] [Table 7-2] [Table 7-3] [Table 7-4] [Table 7-5] Incident Resolution Analysis - Report [Table 8] [Table 9] [Table 9-1] [Table 9-2] [Table 9-3] [Table 9-4]

[0275] Policy Abnormalities - User Group-Based Incidents and Examples

[0276] Figure 28 shows an example of a user group-based incident.

[0277] SPN data collection scheduler and processing service: Collection and parsing / processing of EDL, FQDN, and user ID-to-group mapping data.

[0278] An exemplary security policy analyzer service powered by formal modeling requires firewall operational status information, including (1) comprehensive user-to-group mapping information (required for formal modeling of full fidelity of security policies) and (2) comprehensive user-to-persona mapping information (required for formal modeling of full fidelity of security policies). An exemplary implementation is as follows:

[0279] The GKE microservice "User to Groups Mapping Collector Service" collects user-to-group mapping information. Figure 29 shows an exemplary architecture of the User to Groups Mapping Collector Service. The scheduler / dispatcher fetches a total SPN list (1 RN, MU, EP cloud_instance_ids) for each tenant (periodic trigger service (24 hours or 48 hours)) and distributes it to a process pool for parallel execution of worker processes that collect user groups and user attributes. For on-demand requests, the option of on-demand fetching UserGroups is provided via pubsub notification messages. The collector service uses the firewall data fetch library to retrieve user groups, user ID to group mappings, and user to persona mappings. Command output / file output is stored in GCS storage. For large command outputs, console output may be redirected to a file available on the firewall. For larger command outputs (e.g., 100k user group mapping entries / 800k user attribute records), the cmd-executor plugin / library can be used to collect cmd output dump files, and the cmdfwk API interface can then export the output / dump files to a GCS bucket. A parser module is used for user group / attribute data. The data can be converted to JSON (e.g., from string or XML). The data is normalized for consumption by AIOPS services such as the Security Policy Analyzer Service (which can perform core format modeling and intent satisfaction analysis) and the Application Access Analyzer (which can show a list of user groups permitted to access an application) for the use cases described above.

[0280] Figure 30 shows an exemplary communication diagram associated with a user-to-group mapping collector service. Various approaches can be used to learn group mappings. The first approach is to use direct communication with an on-premises Active Directory service. Information such as LDAP server configuration and group mapping configuration is used. To fetch group mapping information, in some embodiments, the cloud firewall polls the on-premises Active Directory service and uses its existing bandwidth. Network latency can occur for any geographically distant firewall. Using include lists in group mapping can avoid the firewall learning all groups and users on the Active Directory service. The second approach is to use a Directory Sync Proxy (cloud service) or similar service that stores group mapping information from either on-premises or Azure Active Directory. This is a multi-tenant proxy service between the RN / MU cloud firewall and the directory sync service. This approach does not require LDAP server configuration or group mapping configuration information. Instead, the directory sync proxy polls the directory sync service and learns user / group information only for users / groups within the Panorama template configuration. Additionally, a firewall is involved, which acts as the master device, i.e., Panorama (or another service), receiving usernames, user group names, and username-to-group mapping information. The master device may be used to automatically populate usernames and user groups.

[0281] Exemplary User Interface

[0282] Figures 31A and 31B show excerpts from the incident resolution analysis report.

[0283] Figure 32 shows an example of a new rule intent satisfaction analysis report.

[0284] Figure 33 shows details of various parts of the report shown in Figure 32.

[0285] Figures 34A and 34B show examples of breakdown cards.

[0286] Figure 35 shows a partial example of a security policy anomaly / hit count results report.

[0287] Figures 36A to 36C illustrate various forms of security policy incident reports.

[0288] While the embodiments described above are explained in some detail for the purpose of clarifying understanding, the present invention is not limited to the details provided. There are many alternative ways of carrying out the present invention. The disclosed embodiments are illustrative and not limiting.

[0289] Exemplary Embodiments

[0290] A system comprising a processor configured to receive configuration information including at least one policy, build a model using the received configuration information, including normalizing the policy, perform a policy analysis using the model, including performing a pre-change analysis associated with a proposed policy change, and provide the results of the policy analysis as output. There is memory coupled to the processor and configured to provide instructions to the processor. The processor may be further configured to provide proposed recommendations associated with the results of the policy analysis. In some cases, the proposed policy change includes a proposal to add a new rule, and the proposed recommendation is against adding a new rule. In some cases, the proposed policy change includes a proposal to delete an existing rule, and the proposed recommendation is against deleting an existing rule. In some cases, the results include instructions for any conflicts that may arise as a result of making the proposed policy change. In some cases, the results include instructions for any conflicts that may be resolved as a result of making the proposed policy change. In some cases, the configuration information includes live state information extracted from a running firewall. In some cases, at least a portion of the configuration information is received in response to an on-demand request for a policy analysis. In some cases, at least part of the configuration information is received periodically. In some cases, at least part of the configuration information includes metadata. In some cases, the metadata includes at least one of the following: (1) address objects, (2) filters, (3) service groups, (4) DNS resolution information, or (5) application objects. In some cases, building a model involves using a solver. In some cases, performing analysis using a model involves determining conflicts between two rules included in a policy. In some cases, performing analysis using a model involves optimizing a policy using contrashadow analysis. In some cases, performing analysis using a model involves determining intent conflicts.In some cases, using a model to perform an analysis involves checking one or more invariants. In some cases, building a model involves performing group-user mapping.

[0291] A method comprising the steps of: receiving configuration information including at least one policy; building a model using the received configuration information, the model including normalizing the policies; performing a policy analysis using the model, the model including performing a pre-change analysis associated with a proposed policy change; and providing the results of the policy analysis as output.

[0292] A computer program product embodied in a non-temporary computer-readable medium, comprising computer instructions for receiving configuration information including at least one policy; constructing a model using the received configuration information, including normalizing the policy; executing a policy analysis using the model, including performing a pre-change analysis associated with a proposed policy change; and providing the results of the policy analysis as output.

[0293] A system comprising a processor configured to receive configuration information including at least one existing policy, build a model using the received configuration information, including normalizing the policy, analyze the existing policy using the model, and provide the results of the policy analysis as output. There is memory coupled to the processor and configured to provide instructions to the processor. In some cases, the processor is further configured to provide proposed recommendations associated with the results of the policy analysis. In some cases, the recommendations include recommendations to remove redundant policies. In some cases, the recommendations include recommendations to merge two policies. In some cases, the recommendations include recommendations to change rule priorities. In some cases, providing results includes visually indicating policy intent conflicts. In some cases, providing results includes identifying missing enforcement components. In some cases, performing a policy analysis using the model includes determining hit counts. In some cases, performing an analysis using the model includes optimizing the policy using contra-shadow analysis. In some cases, the configuration information includes live state information extracted from a running firewall. In some cases, the configuration information is received in response to on-demand requests for policy analysis. In some cases, the configuration information is received periodically. In some cases, building a model involves using a solver. In some cases, performing an analysis using a model involves checking one or more invariants. In some cases, building a model involves performing group-user mapping. In some cases, performing an analysis using a model involves determining conflicts between two rules included in a policy. In some cases, the processor is configured to build a model in response to receiving queries. In some cases, analyzing an existing policy involves performing a differential analysis between two sets of configuration information.

[0294] A method comprising: receiving configuration information including at least one existing policy; building a model using the received configuration information, the model including normalizing the policy; analyzing the existing policy using the model; and providing the results of the policy analysis as output.

[0295] A computer program product embodied in a non-temporary computer-readable medium, comprising computer instructions for receiving configuration information including at least one existing policy, constructing a model using the received configuration information, including normalizing the policy, analyzing the existing policy using the model, and providing the results of the policy analysis as output.

[0296] A system comprising a processor configured to receive configuration information including at least one policy associated with a live production security appliance, to instantiate the policy in a sandbox environment using the received configuration information, and to evaluate proposed changes to the configuration information using the sandbox environment, including building a model using the received configuration information, and to provide the results of the evaluation as output. There is memory coupled to the processor and configured to provide instructions to the processor. In some cases, at least a portion of the configuration information includes live state information extracted from the live production security appliance. In some cases, evaluating proposed changes includes determining whether a new anomaly has been created as a result of implementing the proposed changes. In some cases, the processor is further configured to implement the proposed changes and perform a re-evaluation. In some cases, the policy is instantiated in a sandbox environment in response to an incident resolution analysis. In some cases, the processor is further configured to receive a list containing one or more incidents. In some cases, the processor is further configured to determine whether one or more items on the list are resolved in a sandbox environment. In some cases, the processor is further configured to receive refresh requests regarding the live production security appliance. In some cases, the processor is further configured to identify differences between the current policy set deployed on the live production security appliance received as a result of a refresh request and the current policy set deployed within the sandbox environment. In some cases, the difference is the addition of rules to the live production security appliance, and the processor is configured to add a copy of the rules to the sandbox environment. In some cases, the difference is the deletion of rules on the live production security appliance, and the processor is configured to delete a copy of the rules in the sandbox environment.In some cases, the difference is a change to a rule on the live production environment security appliance, and the processor is further configured to determine whether making the change in the sandbox environment would result in a rule conflict. In some cases, the processor is configured to prompt the user to resolve any determined rule conflicts.

[0297] A method comprising: receiving configuration information including at least one policy associated with a live production environment security appliance; using the received configuration information to instantiate the policy in a sandbox environment; evaluating proposed changes to the configuration information using the sandbox environment, the method comprising building a model using the received configuration information; and providing the evaluation results as output.

[0298] A computer program product embodied in a non-temporary computer-readable medium, comprising computer instructions for receiving configuration information including at least one policy associated with a live production environment security appliance; using the received configuration information to instantiate the policy in a sandbox environment; evaluating proposed changes to the configuration information using the sandbox environment, and including building a model using the received configuration information; and providing the results of the evaluation as output.< / username> < / username>

Claims

1. It is a system, Receiving configuration information that includes at least one policy, Building a model using the received configuration information, including normalizing the policy, Performing a policy analysis using the aforementioned model, which includes performing a pre-change analysis associated with the proposed policy change, The results of the aforementioned policy analysis will be provided as output. A processor configured to perform the following: A memory coupled to the processor and configured to provide instructions to the processor A system equipped with these features.

2. The system according to claim 1, wherein the processor is further configured to provide proposed recommendations associated with the results of the policy analysis.

3. The system according to claim 2, wherein the proposed policy change includes a proposal to add a new rule, and the proposed recommendation is opposed to adding the new rule.

4. The system according to claim 2, wherein the proposed policy change includes a proposal to delete an existing rule, and the proposed recommendation is opposed to the deletion of the existing rule.

5. The system according to claim 1, wherein the results include instructions for any conflicts that may arise as a result of the proposed policy changes.

6. The system according to claim 1, wherein the results include an indication of a conflict that may be resolved as a result of the proposed policy change.

7. The system according to claim 1, wherein the configuration information includes live status information extracted from a firewall in operation.

8. The system according to claim 1, wherein at least a portion of the aforementioned configuration information is received in response to an on-demand request for policy analysis.

9. The system according to claim 1, wherein at least a portion of the aforementioned configuration information is received periodically.

10. The system according to claim 1, wherein at least a portion of the configuration information includes metadata.

11. The system according to claim 10, wherein the metadata includes at least one of (1) an address object, (2) a filter, (3) a service group, (4) DNS resolution information, or (5) an application object.

12. The system according to claim 1, wherein constructing the aforementioned model includes using a solver.

13. The system according to claim 1, wherein performing an analysis using the model includes determining a conflict between two rules included in the policy.

14. The system according to claim 1, wherein performing an analysis using the model includes optimizing the policy using contrashadow analysis.

15. The system according to claim 1, wherein performing an analysis using the aforementioned model includes determining intent conflicts.

16. The system according to claim 1, wherein performing an analysis using the aforementioned model includes checking one or more invariant conditions.

17. The system according to claim 1, wherein constructing the aforementioned model includes performing group-user mapping.

18. It is a method, A step of receiving configuration information that includes at least one policy, A step of building a model using the received configuration information, comprising the step of normalizing the policy, A step of performing a policy analysis using the aforementioned model, comprising performing a pre-change analysis associated with the proposed policy change, The step of providing the results of the aforementioned policy analysis as output. A method that includes this.

19. A computer program product embodied in a non-temporary computer-readable medium, Receiving configuration information that includes at least one policy, Building a model using the received configuration information, including normalizing the policy, Performing a policy analysis using the aforementioned model, which includes performing a pre-change analysis associated with the proposed policy change, The results of the aforementioned policy analysis will be provided as output. A computer program product that contains computer instructions for performing certain tasks.

20. It is a system, Receiving configuration information that includes at least one existing policy, Building a model using the received configuration information, including normalizing the policy, Analyzing the existing policy using the aforementioned model, The results of the aforementioned policy analysis will be provided as output. A processor configured to perform the following: A memory coupled to the processor and configured to provide instructions to the processor A system equipped with these features.

21. The system according to claim 20, wherein the processor is further configured to provide proposed recommendations associated with the results of the policy analysis.

22. The system according to claim 21, wherein the recommendation includes a recommendation to remove a redundant policy.

23. The system according to claim 21, wherein the recommendation includes a recommendation to merge two policies.

24. The system according to claim 21, wherein the recommendation includes a recommendation to change the rule priority.

25. The system according to claim 20, wherein providing the above results includes visually indicating policy intent conflicts.

26. The system according to claim 20, wherein providing the above results includes identifying missing implementation components.

27. The system according to claim 20, wherein performing the policy analysis using the model includes determining the hit count.

28. The system according to claim 20, wherein performing the analysis using the model includes optimizing the policy using contrashadow analysis.

29. The system according to claim 20, wherein the configuration information includes live status information extracted from a firewall in operation.

30. The system according to claim 20, wherein the configuration information is received in response to an on-demand request for policy analysis.

31. The system according to claim 20, wherein the configuration information is received periodically.

32. The system according to claim 20, wherein constructing the aforementioned model includes using a solver.

33. The system according to claim 20, wherein performing the analysis using the model includes checking one or more invariant conditions.

34. The system according to claim 20, wherein constructing the aforementioned model includes performing group-user mapping.

35. The system according to claim 20, wherein performing an analysis using the model includes determining a conflict between two rules included in the policy.

36. The system according to claim 20, wherein the processor is configured to construct the model in response to receiving a query.

37. The system according to claim 20, wherein analyzing the existing policy includes performing a differential analysis between two sets of configuration information.

38. It is a method, A step of receiving configuration information that includes at least one existing policy, A step of building a model using the received configuration information, including normalizing the policy, and a step of building, The steps include: analyzing the existing policy using the aforementioned model; The step of providing the results of the aforementioned policy analysis as output. A method that includes this.

39. A computer program product embodied in a non-temporary computer-readable medium, Receiving configuration information that includes at least one existing policy, Building a model using the received configuration information, including normalizing the policy, Analyzing the existing policy using the aforementioned model, The results of the aforementioned policy analysis will be provided as output. A computer program product that contains computer instructions for performing certain tasks.

40. It is a system, Receiving configuration information, including at least one policy, associated with the live production environment security appliance, Using the received configuration information, the policy is instantiated in the sandbox environment, Evaluating proposed changes to the configuration information using the aforementioned sandbox environment, including building a model using the received configuration information, The results of the aforementioned evaluation will be provided as output. A processor configured to perform the following: A memory coupled to the processor and configured to provide instructions to the processor A system equipped with these features.

41. The system according to claim 40, wherein at least a portion of the configuration information includes live status information extracted from the live production environment security appliance.

42. The system according to claim 40, wherein evaluating the proposed changes includes determining whether a new anomaly was created as a result of implementing the proposed changes.

43. The system according to claim 40, wherein the processor is further configured to implement the proposed modifications and perform a re-evaluation.

44. The system according to claim 40, wherein the policy is instantiated within the sandbox environment in response to an incident resolution analysis.

45. The system according to claim 40, wherein the processor is further configured to receive a list containing one or more incidents.

46. The system according to claim 45, wherein the processor is further configured to determine whether one or more items on the list are resolved within the sandbox environment.

47. The system according to claim 40, wherein the processor is further configured to receive refresh requests relating to the live production environment security appliance.

48. The system according to claim 47, wherein the processor is further configured to identify the difference between the current policy set deployed on the live production environment security appliance received as a result of the refresh request and the current policy set deployed in the sandbox environment.

49. The system according to claim 48, wherein the difference is the addition of rules to the live production environment security appliance, and the processor is configured to add a copy of the rules to the sandbox environment.

50. The system according to claim 48, wherein the difference is the deletion of a rule in the live production environment security appliance, and the processor is configured to delete a copy of the rule in the sandbox environment.

51. The system according to claim 48, wherein the difference is a change to a rule on the live production environment security appliance, and the processor is further configured to determine whether making the change in the sandbox environment would result in a rule conflict.

52. The system according to claim 51, wherein the processor is configured to prompt the user to resolve conflicts in the determined rules.

53. It is a method, The steps include receiving configuration information, which includes at least one policy, associated with a live production environment security appliance, The steps include: using the received configuration information to instantiate the policy in a sandbox environment; A step of evaluating proposed changes to the configuration information using the sandbox environment, comprising building a model using the received configuration information, A step of providing the results of the aforementioned evaluation as output. A method that includes this.

54. A computer program product embodied in a non-temporary computer-readable medium, Receiving configuration information, including at least one policy, associated with the live production environment security appliance, Using the received configuration information, the policy is instantiated in the sandbox environment, Evaluating proposed changes to the configuration information using the aforementioned sandbox environment, including building a model using the received configuration information, The results of the aforementioned evaluation will be provided as output. A computer program product that contains computer instructions for performing certain tasks.

Images