Next-Generation Datacenter Security Implementation Guidelines

Transcription

1 Next-Generation Datacenter Security Implementation Guidelines March 2015

2 INTRODUCTION 3 DEPLOYMENT OVERVIEW 4 IMPLEMENTATION GUIDELINES 4 PA-7050 Boundary Firewalls to protect north-south traffic 5 Virtual Wire Interfaces 5 Active/Active High Availability 6 VM-Series virtualized firewalls to protect east-west traffic 7 Provisioning the VM-Series with NSX 8 Service VM Deployment 9 Traffic Considerations 10 Panorama centralized management 12 Panorama management architecture 12 Managing the PA-7050 Firewalls 14 Managing the VM-Series Firewalls 14 Policy Update Process 15 Securely enabling datacenter applications 16 PA-7050 Policy deployment 16 VM-Series for NSX policy deployment 17 EXTENDING YOUR DATACENTER 18 Multi Datacenter 18 Public Cloud Bursting 18 DOCUMENTATION REFERENCES 19 PAGE 2

3 Introduction Today s datacenters are rapidly evolving to where they use a mix of physical and virtualized computing, networking and storage components. Regardless of your datacenter topology, recent high-profile breaches have shown attackers using applications commonly found on your network to implement attacks and extract data. These attacks have elevated the need to protect your datacenter with next-generation firewalls and advanced threat prevention features that allow you to: 1. Validate the datacenter application identity and control which applications can communicate with each other. 2. Prevent known and unknown threats within specific datacenter application flows; block malware lateral movement. 3. Grant access to datacenter applications based on user needs and credentials. 4. Ensure policies can scale and keep pace with the dynamic changes in your datacenter. While the implementation of application-level security policies within the physical, virtualized or hybrid datacenter can improve your datacenter security posture, the complexity and variability of many datacenter architectures can introduce certain network integration challenges. To help address the challenge of integrating next-generation security into your physical network, the Palo Alto Networks PA-7050 supports a range of networking modes, including L2, L3, virtual wire, and mixed mode. In a virtualized computing environment, integration can be defined as the level of automation that can be accomplished for services provisioning and policy updates as they relate to the rate of workload change. The VM-Series for VMware NSX network virtualization platform enables you to protect your virtualized environment with application-specific security policies and advanced threat prevention features that are identical to those found in the physical form factor devices. Centralized management through Panorama extends policy consistency to all physical and virtual Palo Alto Networks firewalls in your environment. These implementation guidelines describe how you can deploy the Palo Alto Networks nextgeneration firewall and advanced threat prevention features in both a physical datacenter and VMware with NSX virtualized environment. Key concepts include: Scalability: The modular design of the PA-7050 means that you can add processing power and capacity as needed without impacting traffic processing, while managing the entire unit as a single entity. Virtual firewalls, deployed in tandem with datacenter hosts, linearly increase inspection capacity as your cluster grows. Network integration: Using virtual wire interfaces, no networking protocols or configurations are required, which makes deploying the PA-7050 relatively easy. Virtual wire provides a true transparent mode by logically binding two ports together, while still allowing full inspection and control for all traffic. Reliability: Active/active high availability sets both firewalls to continuously synchronize their configuration and session information, ensuring that in the event of a hardware failure no traffic is lost and solution performance is not degraded. Simplified orchestration and management: Direct integration with VMware NSX through pre-defined APIs helps automate firewall provisioning, while tie-ins with Panorama ensure policies can keep pace with the rate of change to your virtualized workloads. Policy consistency: Panorama serves as a single point of management for all Palo Alto Networks firewalls, both physical and virtual. Policies can be centrally defined and consistently applied to all devices. PAGE 3

4 Deployment Overview There are three key components in this datacenter example: PA-7050 boundary firewalls to secure north-south traffic that traverses the datacenter; VM-Series for NSX virtualized firewalls to secure east-west traffic; and Panorama, the centralized management and reporting platform. PA-7050 boundary firewalls: One pair of PA-7050 firewalls configured in active/active high availability, located between the corporate network and the core datacenter. These systems will process all data entering and leaving the datacenter but are not involved in intra-datacenter traffic. Palo Alto Networks virtual wire interface mode enables simple insertion into existing environments. VM-Series for NSX: A distinct instance of the VM-Series virtual firewall, the VM-Series for NSX is installed on each physical host running VMware. VMware NSX virtualization platform is an integral part of protecting your virtual workloads as it reproduces complete L2 and L3 switching functionality that is decoupled from the underlying physical hardware. NSX then provisions the firewalls and steers traffic to the local firewalls for more granular analysis based on central policy. Panorama central management: Panorama provides a single interface for delivering a consistent, holistic policy across both physical and virtual firewalls. Panorama can be deployed as a virtual appliance or as a dedicated appliance, scaling to address corporate demands of firewall footprint, geography, and compliance. Panorama interfaces with the NSX Manager API, allowing for orchestrated deployment and dynamic updating of environmental changes. Policy consistency and centralized logging are essential components in providing protection from known and unknown threats. Corporate network Figure 1: Palo Alto Networks/NSX Datacenter Cloud Architecture Implementation Guidelines This datacenter security implementation example includes physical form factor firewalls at the datacenter boundary, virtualized form factor firewalls for virtual machine workload security, and security policy management. Points of integration with other datacenter components (e.g., NSX network management, Center host management) are highlighted as a means of implementing a unified security architecture for your datacenter. PAGE 4

5 PA-7050 boundary firewalls to protect north-south traffic The PA-7050 protects datacenters and high-speed networks with firewall throughput of up to 120 Gbps and full threat protection at speeds up to 100 Gbps. To address the computationally intensive nature of full-stack classification and analysis at these speeds, the PA-7050 utilizes a distributed processing architecture, using more than 400 processors spread across the chassis subsystems to achieve predictable datacenter-level performance. Network Processing Card (NPC): Each NPC delivers 20 Gbps of firewall performance using multi-core security-specific processors, along with high-speed networking and content inspection processors. To ensure linear scalability, the physical interfaces on each of the NPCs have been virtually decoupled from the respective security processors, allowing each NPC to act as a traffic management and processing subsystem, sharing the pooled resources of the entire system through the First Packet Processor (FPP). To add capacity, a user need only install a new NPC, no cabling or traffic redirection tasks are required. The FPP intelligently directs incoming traffic to the most appropriate computing resource. Switch Management Card (SMC) and First Packet Processor: The SMC seamlessly marries up to six NPCs together using a 1.2 Tbps backplane and the FPP. The 1.2 Tbps backplane means that each NPC has access to approximately 100 Gbps of traffic capacity, ensuring that there are no bottlenecks as traffic flows through the chassis. In addition, the high-speed backplane provides linear scalability as system capacity and performance are increased with additional NPCs. The FPP utilizes dedicated processing to apply intelligence to incoming traffic, directing it to the appropriate processing resource to maximize throughput efficiency. The FPP is the key to delivering linear scalability to the PA-7050, working in conjunction with each of the network processors on the NPCs to utilize all of the available computing resources as a single, cohesive system. This means that as NPCs and capacity are added, no traffic management changes are required, nor is it necessary to re-cable or reconfigure your PA Log Processing Card (LPC): The LPC uses multi-core processors and 2 TB of RAID 1 storage to offload logging-related activities without impacting the processing required for other management related tasks. The LPC allows you to generate on-system queries and reports from the most recent logs collected, or to forward them to a syslog server for archiving or additional analysis. The result is that the PA-7050 allows you to deploy next-generation security in your datacenters without compromising performance with a single high availability (HA) firewall pair where the overall traffic load will be shared between the two active firewalls (active/active). Key tasks for building out the boundary include: Selection of virtual wire, L2, or L3 firewall interfaces modes. Configuration of HA in active/active or active/passive. Management connection to Panorama. Virtual Wire interfaces In this implementation example, virtual wire was chosen as the networking mode because it eliminates the need for any network reconfiguration. Virtual wire provides a true transparent mode by logically binding two ports together, passing all allowed traffic between them without any switching or routing. Full inspection and control for all traffic is enabled with zero impact on your surrounding devices, while requiring no network protocol configuration. Virtual wire configurations work seamlessly with high availability and scale linearly with addition of new port pairs. When configuring the PA-7050 (or any of our other firewalls), you will map a pair of interfaces to both a virtual wire and a pair of security zones. The designated virtual wire will link the two interfaces together, allowing traffic to pass between them while security policies applied to the security zones will protect the virtual wire traffic. PAGE 5

6 Figure 2 shows a sample grouping of interfaces into virtual wires. Key concepts include one-to-one matching of specific interfaces, grouping into specific security zones, and no requirement to change network addressing. Figure 2: Virtual Wire Interfaces Figure 3 presents corresponding security zone configuration, setting permissions for applications, network addresses, and other traffic elements. Figure 3: Security Zone Configuration Use of virtual wire versus other interface configurations should be based upon each specific datacenter environment. There is no loss in security functionality between virtual wire, L2, and L3 modes. Active/Active high availability Palo Alto Networks firewalls support both active/active and active/passive modes of high availability (HA) to address hardware redundancy requirements that are typically a best practice in business-critical networking and datacenter infrastructures. An HA pair may be co-resident on the same switch or connect through a L3 network to a second device at another location. On the PA-7050, the dedicated HA ports are used to maintain the communication link between the two systems. Failover can be trigged by a range of failure scenarios including interface failure, destination reachability, and heartbeat loss. HA timers can be tuned to optimize convergence and failover performance specific to your firewall deployment. This example uses active/active mode primarily due to the fact that it is commonly used in business-critical datacenter environments. Note that configuring active/passive would follow a similar set of steps. PAGE 6

7 Figure 4 below shows the high availability configuration settings from the device tab, providing details on link status and communication settings. Figure 4: HA Pair Configuration Menu Figure 5 below displays the active/active HA connection status found in the management dashboard. Figure 5: Dashboard Status of Active/Active High Availability Pair The active/active configuration maintains complete state configuration information across both devices. In the event of a failure, the functional firewall will continue to process existing connections without interruption. Once the failed unit achieves recovery, it will automatically re-establish the active/active relationship. VM-Series virtualized firewalls to protect east-west traffic The VM-Series of virtualized next-generation firewalls supports the same security features available in the physical form factor appliances, allowing you to safely enable applications flowing into and across your private, public, and hybrid cloud computing environments. This implementation example will focus on the VM-Series for NSX; a joint solution that enables you to use NSX to provision the VM-Series next-generation firewalls at the same rate that you provision new virtualized workloads. As those workloads change, the integrated solution will allow you to automate the security policy update process to ensure your virtualized applications are protected, no matter how rapid the change. PAGE 7

8 Key steps in deploying VM-Series virtual firewalls include: Configuring Panorama to register as a new service to NSX Manager Deploying virtual firewalls through vcenter and NSX Configuring traffic steering policies Syncing datacenter state using Dynamic Address Groups Deployment of individual virtual firewalls is a hands-free process once the initial orchestration has been put in place. API connectivity between the management components has been designed to provide immediate connectivity, allowing changes made in one environment to seamlessly flow through to the security policy. This orchestration eliminates the requirement for multiple administrative steps across different management platforms. Provisioning the VM-Series with NSX VMware NSX Manager is the VMware point of control for the deployment of the VM-Series for NSX and the steering of traffic for additional analysis. Communication between NSX Manager and Panorama is pre-defined as part of the integrated solution. Figure 6 highlights the message flow between components. Figure 6: Communication between NSX, Panorama, and the VM-Series virtualized firewall Panorama registers the VM-Series firewall as an available service with NSX Manager. This allows the VM-Series to be provisioned on all hosts through NSX Manager/vCenter interaction. This removes the requirement of manually configuring IP addresses within Panorama, further automating the provisioning and management process. Once a VM is deployed, its associated VM-Series firewall will subsequently register with Panorama and obtain the required licenses and associate security polices. In NSX Manager, virtual machines are grouped into logical containers called NSX Security Groups based on desired considerations (e.g., function like a tier of an application). As servers are added, they can dynamically join groups based on specified criteria, including name, security tag, and operating system. Once a security group has been defined in NSX Manager, a Dynamic Address Group is created in Panorama and mapped to the parallel group. This process is key to automating the flow of workload changes made in the NSX environment into the Panorama system. This connection and ongoing communications eliminate the manual intervention required to update all firewalls with these policyrelated changes. PAGE 8

9 Figure 7 below illustrates how the grouping of virtual machines is independent of their physical locations. VMs that reside on the same physical host can be placed into distinct Security Groups for specific levels of control and inspection. Physical Host 1 Physical Host 2 Physical Host 3 Physical Host 4 WFE3 DB3 App1 DB1 App2 WFE2 DB4 DB2 WFE1 WFE4 DB3 App3 WFE NSX Security Group App NSX Security Group DB NSX Security Group WFE1 App1 DB1 WFE2 App2 DB2 WFE3 WFE4 App3 DB3 DB4 DB5 Figure 7: VM Grouping - Physical Host versus Dynamic Address Group This granular level of security enforcement removes legacy physical constraints (e.g., VLAN, subnet, port group) from the infrastructure, allowing complete freedom in VM placement across the datacenter. Service VM deployment Once the VM-Series for NSX is available as a service, it can be deployed to host clusters through NSX Manager. No additional configuration is required for each VM instance created and every VM-Series firewall will connect to Panorama and maintain a consistent policy configuration with other instances. Figure 8 shows a vsphere interface with the Palo Alto Networks NGFW properly registered as a service. Figure 8: Firewall Deployed through NSX PAGE 9

10 Figure 9 displays multiple VM-Series firewalls in the NSX Device Group after being deployed through NSX Manager. Figure 9: NSX-deployed Firewalls in Panorama Traffic considerations The volume of traffic traversing the datacenter boundary can vary widely and the theoretical capacity of a server running VMware is upwards of 32 Gbps. Given these capacities, key considerations for what traffic should be inspected as a means of avoiding a bottleneck include: Specific application architectures High-volume local operations (e.g., storage, backup) Intra-datacenter operations VM mobility External network connection points To help clarify this process, Figure 10 shows an analysis of 440GB of customer bandwidth observed in a production datacenter across 22 hosts. Using the NSX traffic steering features and the applicationcentric classification and inspection in the VM-Series, the 1.3 Gbps of inter-tier traffic represents the total bandwidth that would be inspected across all 22 hosts. Inter-Tier Traffic True East/West traffic between application tiers 1.3 Gbps peak load Unused Capacity Reserved fro redundancy and future growth 220 Gbps North/South Traffic Traffic to and from outside the data center 0.9 Gbps peak load Storage and Backup Virtual file systems and storage traffic plus nightly and weekly backups 185 Gbps peak load Intra-Tier Traffic Traffic within one tier such as web server to web server or database to database 32.8 Gbps peak load Figure 10: Datacenter Traffic Patterns PAGE 10

11 Traffic steering removes limitations imposed by VLANs or IP subnets by grouping VMs regardless of their location, allowing policy to be built purely around guest system functionality. NSX will steer traffic to VM-Series firewalls through the NetX API based on policies associated with their Security Groups. Policy consistency between firewalls ensures that the same rules are applied to each member of a security group, even if those members move to new hosts. The Notify Device Group functionality completes the holistic policy communication, ensuring physical form factor devices (e.g., boundary firewalls) also share common traffic policies for VMs. Physical Host 1 Physical Host 2 Physical Host 3 Physical Host 4 WFE3 DB3 App1 DB1 App2 WFE2 DB4 DB2 WFE1 WFE4 DB3 App3 WFE NSX Security Group App NSX Security Group DB NSX Security Group WFE1 App1 DB1 WFE2 WFE3 Intra-tier traffic steered to VM-Series App2 App3 Intra-tier traffic steered to VM-Series DB2 DB3 Intra-tier traffic not steered to VM-Series WFE4 DB4 DB5 Figure 11: Traffic Steering Inter-Group and Intra-Group Figure 11 compares the physical vs. logical grouping of multiple application tiers (e.g., Web server, back end, database). Specific guest instances within each tier are spread across multiple hosts. NSX will steer traffic between tiers to a VM-Series firewall while allowing traffic within the tier to pass without steering. Rule granularity allows for fine-tuning of steering based on specific requirements around compliance, capacity, and visibility. PAGE 11

12 Figure 12, shows the traffic steering policies created in NSX Manager and displayed in the vsphere interface. Figure 12: Traffic Steering in NSX The percentage of traffic steered will vary by application and corporate preference; however, the majority of traffic (e.g., storage, backup, intra-tier communication) is unlikely to pass through the firewall for additional inspection, thereby eliminating potential bottlenecks. Panorama centralized management Panorama centrally manages all Palo Alto Networks firewalls in the datacenter, providing configuration and policy consistency through a single interface. All of the traffic logs generated by the PA-7050s and the VM-Series firewalls can be aggregated by Panorama for operational analysis and reporting. Panorama management architecture The M-100 management appliance allows you to deploy Panorama either as a single, centralized instance or in a distributed manner, using separate M-100 appliances for management and logging functions respectively. Centralized: In this scenario, all Panorama management and logging functions are consolidated into a single device (with the option for high availability). Distributed: In this scenario, you can separate the management and logging functions across multiple devices, splitting the functions between managers and log collectors. Panorama Manager: The Panorama manager is responsible for handling the tasks associated with policy and device configuration across all managed devices. The manager does not store log data locally; rather it uses separate log collectors for handling log data. The manager analyzes the data stored in the log collectors for centralized reporting. Panorama Log Collector: Organizations with high logging volume and retention requirements can deploy dedicated Panorama log collector devices that will aggregate log information from multiple managed firewalls. The separation of management and log collection, along with role-based administration enables you to optimize your Panorama deployment in order to meet scalability, organizational or geographical requirements. PAGE 12

13 Manager Log Collector Log Collector VM-1000-HV VM-1000-HV VM-1000-HV VM-1000-HV Figure 13: Panorama Architecture Hierarchy As shown in Figure 13, Panorama manager can speak to both firewalls with M-100 log collectors/log aggregators. Additional key features of the Panorama architecture include: Scalability: A single instance of Panorama can scale to address vcenter cluster capacity. Accessibility: Log data is available to external event management systems (e.g., ArcSight, Splunk). Redundancy: Panorama supports an active/passive HA architecture, regardless of the choice for physical or virtual footprint. Role-based administration: Granular access controls allow administrator privileges to be assigned to specific individuals or device groups, removing the need for distinct management systems based on corporate roles or access policies. Panorama can also be deployed as a virtual appliance, allowing organizations to better support their virtualization initiatives and consolidate rack space, which is sometimes limited or costly in a datacenter. Providing the choice of either a hardware or virtualized platform, as well as the choice to combine or separate the Panorama functions, provides you with the maximum flexibility for managing multiple Palo Alto Networks firewalls in a distributed environment. Panorama VM < 10 devices < 10,000 logs/sec Sites with need for virtual appliance M-100 Panorama M-100 < 100 devices < 10,000 logs/sec Manager Log Collector Log Collector Log Collector Panorama Distributed Architecture < 1,000 devices > 10,000 logs/sec (50,000 per collector) Deployments with need for collector proximity Figure 14: Panorama Deployment Recommendations Guidelines for sizing your Panorama deployment are outlined in Figure 14; considerations include firewall count, event logging rate, and overall datacenter architecture. PAGE 13

14 Managing the PA-7050 firewalls To enable centralized firewall management of the PA-7050s, add the Panorama IP address(es) on each firewall. Then, add the systems under Managed Devices on the Panorama console. Physical firewalls (e.g., PA-7050s) are not deployed through NSX, but are connected through the use of Notify Device Groups functionality. This ensures their policies remain consistent with VM-Series firewalls also managed through Panorama. Managing the VM-Series firewalls Connecting NSX Security Groups to Panorama Dynamic Address Groups is key to establishing seamless orchestration. Figure 15 shows a few security groups already defined in the vsphere interface. Figure 15: VMware NSX Security Groups After creation of the NSX Security Groups, directly map Dynamic Address Groups to them one for one. Figure 16 demonstrates the creation of a corresponding group within Panorama. Figure 16: Dynamic Address Group Configuration PAGE 14

15 With the connection between NSX Security Groups and Palo Alto Networks Dynamic Address Groups established, new virtual machines are properly secured without any changes required on Panorama. Figure 17 shows the connection between the two in the Panorama interface. Figure 17: Security Group/Dynamic Address Group Connectivity Policy update process In both physical and virtualized network environments, you are challenged with managing the changes that may occur between compute workload additions, removals, or modifications as well as how quickly a security policy can be deployed. To help minimize these delays, a rich set of native management features streamlines policy deployment. This way, security keeps pace with the changes in your compute workloads. When Center creates a new VM or stops an existing one, it notifies NSX Manager. NSX Manager then notifies Panorama of these changes, which in turn pushes the updates out to every firewall. This process is outlined in Figure 18: A change is made at the VM level that impacts NSX Security Group membership, possibly changing traffic steering. The connection to Panorama updates associated security functionality, which then pushes changes to all VM-Series firewalls. Figure 18: Policy Change Process Flow PAGE 15

16 The result is a dramatic reduction in the delay that may occur between workload changes and security policy updates. As a means of further automating and streamlining policy updates, a fully documented REST-based API allows you to integrate with third-party cloud orchestration solutions, such as OpenStack and CloudStack. Securely enabling datacenter applications The next set of implementation guidelines focuses on the set of security policies you might use to protect your datacenter. The policy examples outlined in this section are based on implementing Microsoft SharePoint in both a physical and a virtualized datacenter. These policies highlight how you can extend the practice of network segmentation to grant datacenter access based on specific applications, allowing users to access the application based on their credentials and blocking both known and unknown threats at each segmentation point. PA-7050 policy deployment Panorama gives you the ability to define rules that are shared across all firewalls, or you can define rules that are specific to an individual firewall or a subset thereof. To deploy a policy to the PA-7050, you would access the individual DC Edge firewalls from within Panorama, as shown in Figure 19. Figure 19: DC Edge FW context switching in Panorama Once you have switched context in Panorama to the DC Edge firewalls, you can define policies to protect the SharePoint environment, as shown in Figure 20. X The policies implemented will enforce positive security model rules that: Subnet3 Subnet3 Subnet3 Allow only the Web front end to communicate with the SharePoint application. Allow only the SharePoint application to communicate with the SQL database. WFE SharePoint MS SQL Figure 20: Controlling applications within a SharePoint environment PAGE 16

17 When viewed in the Panorama policy management interface, the policy described above will contain two rules. The first rule allows the HR group to access the Web front end servers and that set of traffic is inspected for known and unknown threats as defined in the Profile column. The group of applications that makes up the Web front end servers is highlighted in Figure 21 below. Shown in the second rule is the set of remote server management tools that only the IT group is allowed to use within the datacenter. Limiting access to remote server management to only the IT group will help eliminate the rogue use of these types of applications within your organization. Figure 21: Setting policy to control Web front end traffic VM-Series for NSX policy deployment Deploying a policy to the VM-Series for NSX would follow similar steps. As displayed in Figure 22 below, you would switch context in Panorama to the NSX Device Group, which will display a series of policies that controls traffic moving from VM-to-VM based on the application. Note that the applications used in Source and Destination are the Dynamic Address Groups that were defined earlier and shown in Figure 17. This level of control will enable you to exert positive security model policies that will allow the applications you expressly define while implicitly blocking all others. Figure 22: Setting policy to control all SharePoint and related application traffic Oftentimes the question of whether or not application control is applicable in the datacenter arises due to the limited number of known applications that are typically in use, the theory being that we know which applications are in use in the datacenter and can therefore more easily secure them. The reality is that recent high-profile breaches have shown that attackers will use applications commonly found on your network (including your datacenters) to implement their attacks and extract your data. Implementing policy-based control that grants access to specific datacenter applications (not the ports), while preventing known and unknown threats for a defined set of users, will help to improve your security posture by dramatically reducing the volume of applications that might be traversing your datacenter firewalls. PAGE 17

18 Extending your datacenter Multi Datacenter Extension of consistent policy across multiple datacenters is managed through Panorama and its distributed architecture. Whether NSX Manager and vcenter are responsible for one or more distinct datacenter groups, the same controls and scale are available through a single instance of Panorama. Europe datacenter Log collector Headquarters Americas datacenter Panorama Log collector Policy Management Log Query Reporting Traffic Analysis Asia Pacific datacenter Log collector Figure 23: Multi-Datacenter Architecture Use of the HA active/passive architecture can further extend operational resilience when locating a Panorama server at multiple sites. Public Cloud Bursting Policy enforcement can be extended outside direct corporate control into various hybrid cloud offerings. The example below demonstrates a solution deployed with Amazon Web Services. Figure 24: Amazon Web Services Hybrid Cloud Architecture PAGE 18

19 Amazon customers may manage VM-Series virtual firewall instances directly through Panorama, creating secure tunnels from Palo Alto Networks firewalls located at their corporate sites into Amazon. All data traffic is encrypted, regardless of whether public Internet or direct connect solutions are utilized, and each device is securely managed through the common Panorama interface. Documentation References PAN-OS 6.1 Administrator s Guide documentation/61/pan-os/pan-os.html Virtual Wire chapter_7.html High Availability documentation/61/pan-os/pan-os/section_5/chapter_1.html#54919 Panorama documentation/61/panorama/panorama_adminguide/section_4/chapter_1.html# Great America Parkway Santa Clara, CA Main: Sales: Support: Copyright 2015, Palo Alto Networks, Inc. All rights reserved. Palo Alto Networks, the Palo Alto Networks Logo, PAN-OS, App-ID and Panorama are trademarks of Palo Alto Networks, Inc. All specifications are subject to change without notice. Palo Alto Networks assumes no responsibility for any inaccuracies in this document or for any obligation to update information in this document. Palo Alto Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. PAN_NGDCSIG_040615