Presentation on theme: "Migrating from Juniper to Palo Alto Networks"— Presentation transcript:
1 Migrating from Juniper to Palo Alto Networks Click to edit Master text stylesSecond levelThird levelFourth levelFifth level11
2 Agenda Overview Key Differences Key Reasons to Migrate Migration Best PracticesQ&A
3 Applications Have Changed, Firewalls Haven’t The fundamental problem that we set out to solve is this: applications have changed, the firewall has not kept pace. And what we sometimes forget is that the firewall was designed to act as the security boundary for your network. It sees all traffic and enables access.The evolution of the application landscape has not happened over night – although it has accelerated dramatically in recent years.Antivirus applications began using port 80 as their avenue for updates back in AV is not a web application. The vendors did this to simplify access and better support their customers.AOL instant messenger (AIM) used to prompt you with “Find an open port?” if it could not establish a connection.BitTorrent, Skype both port hop and MS sharepoint uses a range of ports.Finally, MS-Lync – the messaging component for MS live 365 requires port 443, 3478 (stun), 5223 and a range of ports between 20,000-45,000 and 50,000-59,999.These are just a few examples of how applications have changed to mainly simplify access.Think about it, if you’re an application developer, you want your application used – so you will do what is necessary to achieve that goal.The ramifications of these changes result in an increase in business and security risks - applications act as (1) a threat vector ( delivering a video URL but is really malware) and (2) they are threat targets (SQL injection attacks), and (3) they act as the command and control/exfiltration avenue.So while applications were rapidly evolving, port-based firewalls were stuck in the late 1990s – they did not keep pace. To try and address the problem, the industry’s response has been to sell more stuff!Goals of this slide.This slide establishes the problem: Firewalls have always been designed to be the security boundary. They have not kept pace with the application trends.Use interesting examples that are not Facebook and Twitter to show that applications have changes firewalls have not.Use examples of applications that may use evasive techniques to simplify use and in so doing, avoid detection.Use applications that change state as added functions are used – they are hard for UTMS to identify, control and enable.Network security policy is enforced at the firewallSees all trafficDefines boundaryEnables accessTraditional firewalls don’t work any more
7 Juniper SRX Overview SRX = Security services gateways. Successor to the NetScreen/ScreenOS productsUses JUNOS – a high performance routing OSTwo platform familiesEnterprise and datacenter (SRX1400 to SRX5800)Small, distributed enterprise (SRX100 to SRX650)AppSecure addresses next-generation firewall featuresNGFW feature components added to Stateful inspectionAppTrack (visibility), AppFW (id apps), AppQoS (QoS) and AppDoS (DoS)Application identification and control are performed after an initial port-based firewall decision is made
10 Top 3 Reasons to Migrate Context-based policy management Positive control model?APT prevention
11 context-based policy management file-sharingURL categorypdffile typeroadmap.pdffile namebjacobsuserprodmgmtgroupcanadadestination countrySSLprotocolHTTPslideshareapplicationslideshare-uploadingapplication functionunknownURL categoryshipment.exefile namechinadestination country344 KBANIMATED SLIDE - practice344 KB. Somewhat meaningless. Sure, its roughly 1/3 of a MB, but so what.<click> traditional security will give you info on the IP addresses, and the port. So now you have a bit more context, but not much more. Its something going across port 443. may or may not be using SSL. But what else do you know?<click> But what if you had who the user was, which group they are in?<click> and wouldn’t the actual protocol be helpful?<click> and the application, and possibly the function in use?<click> the file type and file nameThe context of the traffic being observed is more meaningful, allowing you to make more intelligent decisions, respond more rapidly to security incidents, generate more complete reports.Think about what you can do, from a security perspective, with this data.source IPdestination IPtcp/443destination port
12 Shared Context Highlights the Value of Integration Reporting | Logging | Forensics | PanoramaApps | Functions | Users | IPS | AV | AS | Malware | QoS | Files | PatternsSafe Enablement PoliciesApplicationsUsersContent
13 Operational Efficiency: Unified Policy Control Users/User GroupsApplicationThreat PreventionAntivirusAnti-SpywareVulnerability ProtectionURL FilteringWildFireWe don't use the default port for identifying applications - it is only used when you set policy and use the service column. For example, if you created a policy to allow squirrelmail and set service to "application default", then we would only allow squirrelmail to run on port 80. If we decrypt SSL and see squirrelmail inside (port 443), then we would block it with the policy. Single Policy for application, user and content (threat prevention)
14 AppSecure Management Different policy management components AppSecure Management ChallengesMultiple management components required – Space, CLI, STRM = more work, less visibility & control, slows responsivenessUser information is not natively integrated – requires UAC + Pulse = more work, more devices and components to manage, less effective
15 Application Control in the Firewall positive controlApplication Control in the FirewallAllow FacebookXFirewallApp-IDPolicy DecisionKey DifferenceBenefitSingle firewall policyLess work, more secure. Administrative effort is reduced; potential reconciliation holes eliminated.Positive control modelAllow by policy, all else is denied. It’s a firewall.Single log databaseLess work, more visibility. Policy decisions based on complete information.Systematically manage unknownsLess work, more secure. Quickly identify high risk traffic and systematically manage it.Shared contextLess work, more secure. App, content and user are pervasive - visibility, policy control, logging, reportingWe believe application enablement belongs in the FW, not in a secondary scanning process.Recall that a firewall uses a positive control security model – meaning, allow what you define, block all else.Using that as the premise, here is how we might enable facebook. Single policy to allow it, [CLICK} and all else is blocked.The benefits of the application enablement in the FW are significantSingle rule base means less work – competitive offerings require multiple policies with duplicate data entry. Better security with a single policy – eliminates possible traffic gaps, reconciliation holes left open by the two policies.Positive security – means new apps that uses may want to try are block implicitly (or explicitly depending on the practices followed).Single log db means a single view into whats happening on the network.Most importantly, FW based enablement gives you more control over unknown traffic. Unknown traffic represents 5-8% on every network. We knew from day 1 unknowns would exist – it can be an internal app, a commercial off-the-shelf (COTS) app, or a threat. Any traffic not IDed by our mechanisms falls into unknown udp or unknown tcp. From there, you can quickly analyze it, set policy on it categorically, and systematically manage it.For unknown Commercial Applications, using visibility tools, you can quickly determine if the traffic is a commercial off-the-shelf (COTS) application or not. If it is a COTS application, then you can use the packet capture feature you can then record the traffic and submit it for App-ID development. The new App-ID is developed, tested, then added to the database for all users in our scheduled updates.Internal or Custom Applications: Next, you can determine if the application is internal or custom using the visibility tools or the log viewer. If the traffic is an internal application, you can create a custom App-ID using the exposed protocol and application decoders. Once the custom App-ID is developed, your internal application is classified and inspected in the same manner as applications with standard App-IDs. You can enable the internal application via policy, inspect it for threats, shape it using QoS and so on. Custom App-IDs are managed in a separate database on the device, ensuring they are not impacted by the weekly App-ID updates.Custom traffic as a threat: Once the internal or COTS applications have been addressed, the third possible identity of the unknown traffic is that it is a threat. Here too, you can quickly determine the risk levels using the behavioral botnet report or other forensics tools to isolate the characteristics and apply appropriate policy control.
16 Application Control as an Add-on Facebook allowed…what about the other 299 apps?Policy Decision #1FirewallAllow port 80Open ports toallow the applicationPolicy Decision #2App-Control Add-onApplicationsAllow Facebooktcp serviceon port 80Key DifferenceRamificationsTwo separate policiesMore Work. Two policies, more admin effortPossible security holes. No policy reconciliation toolsTwo separate policy decisionsWeakens the deny-all-else premise. Applications allowed by FW decisionTwo separate log databasesLess visibility with more effort. Informed policy decisions require more effort , slows reaction timeNo concept of unknown trafficIncreased risk. Unknown is found on every network = low volume, high riskMore work, less flexible. Significant effort to investigate; limited managementNo shared contextMore work, less knowledge, slows reaction time. Finding and correlating app, user, content requires significant effortThere are some fundamental differences in competitive offerings that that cannot be overlooked, starting with their foundation. They are all based on stateful inspection – and stateful inspection is making all access control decisions based on port and protocol. This cannot be changed, yet it is easily bypassed by many of today’s applications. Existing firewall vendors try to address application enablement by adding application control features to their Stateful inspection firewall, much like they have done with IPS. There are several significant ramifications to this add-on approach.Multiple policies with duplicate information increases management effort. A port-based firewall plus application control approach means you will need to build and manage firewall policy with source, destination, user, port, and action, etc. and an application control policy, with the same information adding application and action. If your organization is like most, then you likely have hundreds, even thousands of firewall rules. A multiple policy rulebase approach will not only increase administrative overhead – it may also increase both business and security risks unnecessarily. Palo Alto Networks uses a single, unified policy editor that allows you to use application, user and content as the basis for your secure enablement policies.Port-based ‘allow’ rule + app ctrl rule weakens the FW ‘deny all else’ premise. The always-on nature of port-based traffic classification, means your incumbent firewall will first need to open? the application default port controlling the application. To control Facebook, you need to allow tcp/80 or tcp/443. Based on the Application Usage and Risk Report, you may be allowing 297 (25% of the average enterprise application mix) other applications that you may or may not want on the network. This means the strength of a default deny all policy is significantly weakened. As soon as traffic hits a Palo Alto Networks firewall, App-ID immediately identifies what the application is, across all ports, all the time. Access control decisions are made based on the application and default deny all can be maintained.Systematic management of unknown traffic. Unknown traffic epitomizes the 80%-20% rule – it is a small amount of traffic on every network, but it is high risk. Unknown traffic can be a custom application, an unidentified commercial application, or a threat. Incumbent vendors have no way to systematically find and manage that unknown traffic. To be clear, all of the traffic is logged by the firewall, but the applications are logged separately and are a subset, making unknown traffic management nearly impossible. Common competitive responses to unknonw traffic is to block it, which may cripple the business by blocking a critical internal app.We categorize unknown traffic, which allows you to find internal applications and create a custom App-ID; do a PCAP for unidentified commercial applications and submit them for App-ID development; use the logging and reporting features to see if it is a threat. You are able to systematically manage unknown traffic down to a small, low risk amount – all based on policy.*Based on Palo Alto Networks Application Usage and Risk Report
17 A Unique Approach to Protecting your Network APT protectionA Unique Approach to Protecting your NetworkScan ALL applications (including SSL traffic) to secure all avenues in/out of a network, reduce the attack surface area, and provide context for forensicsPrevent attacks across ALL attack vectors (exploit, malware, DNS, command & control, and URL) with content-based signaturesDetect zero day malware & exploits using public/private cloud and automatically creates signatures for global customer baseOur platform is unique in its ability to natively classify and inspect all traffic, inclusive of applications, threats and content. And then we tie that traffic to the user, regardless of location or device type.Box 1: We scan ALL applications (including SSL traffic) to secure all avenues in/out of a network, applying positive control model security in order to reduce the attack surface area, and provide context for forensicsBox 2: Prevents attacks across ALL attack vectors (exploit, malware, DNS, command & control, and URL) with content-based signaturesBox 3 and feedback loop: Detects zero day malware & exploits using public/private cloud and automatically creates signatures for global customer baseOur approach is applicable across the network. At the gateway, in the datacenter, for segmentation and for carriers.
18 WildFire: Stopping the Unknowns 10Gbps advanced threat visibility and prevention on all traffic, all ports (web, , SMB, etc.)Malware run in the cloud with open internet access to discover C2 protocols, domains, URLs and staged malware downloadsNew malware signatures automatically created by WildFire and delivered to customers globallyStream-based malware engine performs ongoing in-line enforcementOn-premises WildFire appliance available for additional data privacyWildFireTMWildFire Appliance(optional)Anti-malware signaturesDNS intelligenceMalware URL databaseAnti-C2 signaturesSoak sites, sinkholes,3rd party sourcesWildFire UsersGlobal intelligence and protection delivered to all usersCommand-and-controlStaged malware downloadsHost ID and data exfil
19 Feb 2014: Continued Security Business Uncertainty security commitment?Feb 2014: Continued Security Business UncertaintyThe company could cut $200 million in annual operating costs and buy back $2.5 billion in stock immediately and an additional $1 billion in 2015, Elliott said in a presentation of its proposals. Juniper should also review its security and switching businesses to streamline products, and “focus on projects and areas where Juniper has clear competencies and the greatest risk-adjusted return on investment,” Elliott said.
20 Our next-generation enterprise security platform Next-Generation FirewallThreat Intelligence CloudInspects all trafficBlocks known threatsSends unknown to cloudExtensible to mobile & virtual networksGathers potential threats from network and endpointsAnalyses and correlates threat intelligenceDisseminates threat intelligence to network and endpointsOur next-generation firewall provides the ability to inspect all traffic going in and out of your organization regardless of which port or protocol is used, or whether that traffic is encrypted. We know attacks have evolved to use new vectors that take advantage of blind spots that exist within traditional security infrastructure such as stateful inspection firewalls. Our next-generation firewall was not only designed to eliminate those blind spots, it was also designed to use that visibility to safely enable those applications that are critical to your business’ success. This is a key distinction in our approach. By utilizing the application identification and control features (App-ID) with user identification (User-ID) you can regain valuable control of your network; applying positive policies to eliminate unnecessary risk; and ultimately reduce down your attack surface and apply application specific threat prevention policies to block known threats.WildFire, the right had side makes up the basis of our threat intelligence cloud. It was built for the purpose of detecting unique threats that had never been seen before. Hopefully we agree that detection alone is not sufficient. For that reason we closely integrated WildFire with Threat Prevention which includes IPS, anti-malware, and command-and-control. WildFire also closely integrates with a third cloud-based service, URL Filtering. This ensures that as new forms of malware, vulnerabilities, command-and-control servers, or malicious URLs are discovered, those new signatures created out of WildFire are automatically routed to your prevention tools. We’ve also integrated WildFire into Global Protect allowing you to extend your perimeter defenses out to the mobile worker. Today we have thousands of customers that have subscribed to these services to prevent advanced attacks from breaching their organization.But what if that attack does get through? More recently we’ve introduced an innovative new approach for protecting the endpoint, also available as a cloud service. This last line of defense protects organizations against advanced zero day exploits that manage to avoid detection and make it to an endpoint system. As it turns out, while there are thousands of vulnerabilities uncovered each year, there are only around 23 techniques that can be used by attackers to actually exploit that vulnerability on a system. These techniques are hard science. In fact they are so hard they don’t change that often. Maybe you’ll see one or two new techniques emerge within an entire year. Our approach once again focused on finding the most minimally invasive, yet effective solution for defeating these advanced threats. We’ve been very effective at doing just that. In fact since this technology was first released we’ve been able to stop virtually every Windows-based zero day. Now, to complete the triangle we’ve integrated our endpoint technology to our threat intelligence cloud. We don’t just prevent the attack and call it a day. Once a new exploit is detected we send it to our cloud for further inspection. In the process we learn a lot! We’re discovering new vulnerabilities, malicious URLs, command-and-control servers, new forms malware, and building signatures against that new intelligence. And much like what we do today with WildFire, those signatures are automatically distributed to our global customer base.I’ll close here with the point that this platform exists today, this is not a future. Our success as a company supports the acceptance of our vision and ability to execute against that vision. It’s also a testament that what we’ve built can protect some of the most demanding environments out there.Advanced Endpoint ProtectionInspects all processes and filesPrevents both known & unknown exploitsIntegrates with cloud to prevent known & unknown malware
21 Migration Best Practices From Consulting Services
22 Perceived Port/Protocol/IP Migration Challenges Cost – people and timePerception of workload and a lot of tedious typing to migrate from your current configurationRiskMoving configurations can seem daunting and seem to involve a lot of riskLegacy policyPolicies were originally created with the mindset of port / protocol / IP and not optimized for applications and usersLost historyMany companies face “policy bloat” and “cruft” in their firewall configurations
23 Performing the Migration An effective migration requires a combination of people, process, and technology to efficiently and effectively migrate from legacy firewalls to Palo Alto Networks This approach reduces potential risks and lowers cost.The engineers performing the task need knowledge of the current platform and Palo Alto NetworksMigration tools can automate the routine conversion tasks reducing effort (cost) and risk.We’ve spent some time taking a look at the different approaches, so now let’s drill down a little deeper into the process of performing the migration.Migrating a config takes thought, care, and experience, and it is critical to have experienced engineers perform the migration. They need to understand how the legacy firewall worked as well as the Palo Alto Networks firewall, and how they fit into the surrounding environment. They need to be able to build the new configurations and make modifications where necessary to maintain functionality, and they need to monitor the firewalls after the cutover and make adjustments, if necessary.A structured process is also key to a successful migration. It is important to follow a process that has been tested again and again in the field and proven successful.The final piece, and probably least important, is supporting technology. Having migration tools to automate some of the migration steps can drastically reduce the time required to migrate large configurations, and lower risk due to human errors. This is in no way a substitute for experienced engineers and a proven process.Any migration should follow a proven methodology and process (audit, analyze, migrate, cutover)
24 The Spectrum of Conversion Options Many options exist when performing the initial conversion from IP/port/protocol to user/application-based policiesThere is a spectrum of options each with pros/cons and potential riskLess riskLower effortSmall rewardMore riskHigher effortBig rewardInitial policy / object conversion optionsPhase 1 like for likePhase 2 moving to app based, etc.Lessen risk in early stagesMigrate objects and policies “as is”Policy / object “cleanup”Policy / object “cleanup” + move to application policiesMigrate to user/application policies
25 Palo Alto Networks Firewall Migration Tool Web 2.0 application in a VMWare imageParses configurations into a database backend and web UI frontendProvides multiple options:Migrate objects & policiesMigrate used or both used / unused objectsAllows “in-place” editing of PAN-OS objects, services & policies prior to exportingDoesn’t replace the need for people with expertise in the current technology and PAN-OSGoal of the tool is 85+% policy migration automationLater versions NAT translation, Cisco, JNPR, NetScreenCheckpoint R75 in later versions, objects, NAT rules, etc.Mention the manual part of review
26 Migration Process - Walk Through Migrate L4 to L4 (Phase I)Reduce amount of Rules “Combining” similar ones. By destination address for example.Clean all the unused objects. Clean disabled rules.Change services based on other protocols than TCP/UDP to Palo Alto Networks App-IDs. Example: IKE, IPSEC, GREChange services with ALG to Palo Alto Networks App-IDs. Example: FTP, SIPReview & add all NAT rules. Check the security policies to match the destination zones when destination NAT is defined.
27 Example: Reducing Policy Rules Due to the simplistic nature of the security rules, we can often combine many policies into one, especially if we can utilize App-IDiOS config, generated GRE & IPSec rulesLater versions of MT Ping & ICMP
28 Migration Process - Walk Through (Cont’d) Migrate from L4 to L7 (Phase II)Put the migrated L4 policy in your Palo Alto Networks device. Connect to your network.In-line ( L3 , L2, VWire ).Off-line (TAP mode).From this moment the Palo Alto Networks device will classify all the traffic in your network. That means it will identify all the applications and generate all the log entries for the application traffic.From the current logs we can extract the applications seen by each rule and we can start to swap from L4 Services to App-ID without to break anything.
29 Additional Migration Considerations Once we have changed services by App-ID, change the service to “application-default” or leave the previous port. Reduce the surface to detect the application to this port if it always uses the same.Control the UnknownFrom the logs check for unknown traffic (tcp/udp/p2p) and generate custom signatures to identify custom apps. Use Application Override when need.If you have URL filtering activated check for app we-browsing and the Category is “unknown”. Generate proper App-id to identify this traffic as your custom app instead of web-browsing. This is more efficient.Block all the unknown.Threat PreventionActivate WildFire where the apps can transfer files (PE, PDF, Office, APK, Jar).Activate IPS/AV/SPY profiles to your rules. Use the migration tool to do it massively.User-IDIntegrate with your user repository to move from static ip address to users and groups. Improve visibility and win in mobility.
30 Migration Tool – Juniper Caveats Objects in Address-BooksCheck if an object was defined in many address-books (based by zone) If equal, import only once.Check if the IP address/ port is different based in the zone. If different, use different names to avoid duplicates errors.Policies and ZonesReduction of policies only because we can use more than one zone by rule or use the zone ANY. Potential for significant rule reductions here.Customer with 4,623 rules. Direct reduction by 3 only playing with zones.
31 Best Practices to Make Your Migration Successful Align people, process and technologyUnderstand conversion options and optimize policies (ports vs. apps)Utilize migration tool to automate conversion tasks (Objects, Rule base)Validation of accuracy and verification of changesPost migrationImplement custom App-IDsRule cleanup - “Highlight Unused Policies” feature to cleanup post-migrationEnable additional security features (User-ID, Content-ID, WildFire, etc…)
32 Get Your Free AVR Report Find out which applications and threats are on your network with a FREE assessment from Palo Alto NetworksPalo Alto Networks Application Visibility and Risk Report (AVR) :Request an evaluationPlace Palo Alto Networks inside your networkWe’ll tell you what applications and threats we see in your network!Register today at: