Securing industry mobile initiatives beyond BYOD

posted by: on June 12, 2013 9:52 AM

filed in: Cybersecurity, Mobility
tagged: ,

Securing the deployment of mobile devices is often discussed in the context of employees using their personal smartphone or tablet for basic work-related activities such as email and collaborative tasks. The primary purpose is flexibility, productivity and the ability to remain connected while traveling, working from home or working after hours.

In some industries, the use of mobile devices goes much deeper and intersects with core business processes. In healthcare, clinicians use tablets to capture, review and update patient information on the bedside or at home, read vital data and make critical decisions. In banking and online retail, mobile payment is being deployed as a way to lower costs and gain market share. As the use of wireless and mobile technologies becomes more pervasive, the scope of the security needs must expand from protecting pointed interactions to covering a myriad of use cases that impact hundreds of mobile applications, and the enterprise data they access.

…Continue reading

A Private Option for WildFire

posted by: on June 3, 2013 9:52 AM

filed in: Cloud Computing, Data Center, Firewall
tagged: , , , ,


Today we released the WF-500, which is the latest addition to our WildFire solution dedicated to detecting and blocking unknown malware and targeted cyber attacks. As many of you know, one of the core design principles of WildFire is the marriage of any and all of your next-generation firewalls with a cloud-based malware analysis environment where new or unknown files can be executed and observed in order to determine if they harbor malicious behaviors. The WF-500 provides the option for customers to deploy a private version of the WildFire analysis environment on your private network. For reference, you can read all about WildFire and the WF-500 here.

It’s important to note that when we say “cloud” we aren’t just euphemistically referring to the Internet, or the marketing use of “The Cloud” that will swoop in to magically solve all IT problems. We are talking about actual cloud-computing, and there are important reasons why this architecture is required for addressing the challenges of modern malware and threats. First and foremost, the active analysis of unknown files demands massive amounts of compute. Each file needs its own fully virtualized environment including OS, browsers and Internet connectivity. And to protect against real attacks, we must be performing this type of analysis on all unknown files from all of our network ingress points. So in short, we have a technical requirement to support many distributed points of presence, with each requiring massive computing resources. This is a job that screams cloud computing, and this is what we have built with WildFire.

In a WildFire deployment, all firewalls can be linked with a WildFire cloud (either the public WildFire cloud available to all customers, or a private WildFire cloud using one or more WF-500s deployed on your network). The analysis is identical whether performed in the public or a private cloud, and in both cases all firewalls leverage a shared set of computing resources. In both cases, the single cloud provides support for the many firewalls.

This is far more efficient than the other commonly seen strategy where malware analysis devices are deployed as yet another security helper device, with a sandbox tied to each firewall. This is not only inefficient, it creates choke-points where the ability to protect against threats is limited by the number of files the sandbox can handle. Unlike everything else in the network stack where solutions are sized in terms of throughput, a helper sandbox must be sized in terms of how many files could hit that ingress point.

Of course, once malware is detected we will want to do something about it, and this is where WildFire can close the loop. WildFire is linked to the next-generation firewall, which not only has true, in-line enforcement capabilities, it also has native stream-based antimalware, native IPS for controlling malware command-and-control, native URL filtering to block sites associated with the newly found malware, and native DNS-based signatures to identify the unique DNS patterns of malware. This provides enforcement points across the malware lifecycle in a device that is built for high-speed enforcement.

So just as a reminder, if you are not using WildFire today, you can always use the basic features of the WildFire public cloud for free – just enable it on your firewall. If you are interested in taking a look at the WF-500 option in your network, just let us know and we will get you set up.

Next-Generation Firewalls for Your SDN Network

posted by: on May 15, 2013 8:45 AM

filed in: Firewall
tagged: , , ,

Software-defined networking (SDN) is the new buzzword of 2013, as demonstrated by the number of startups that have proliferated in this space, and vendors that are positioning themselves in this new market. If you’re considering SDN for your network, I encourage you to check out my latest SecurityWeek article, where I describe SDN components and its architectural benefits.

In short, SDN is the physical separation of control plane from the data plane, so that instead of each networking device independently forwarding packets to the next hop, the controls are centralized on “SDN controllers”.  SDN networks therefore provide flexibility, programmability and simplicity to network operations, where traffic can be steered, optimized or customized without requiring physical wiring changes.

Where does security fit in an SDN network? We believe security correspondingly needs to be more dynamic, automated and programmable as well. The good news if you have a Palo Alto Networks next-generation firewall is we already interoperate with SDN networks today. In an SDN network, SDN controllers can program our firewalls using our REST-based API, with dynamic address objects supporting dynamic redirection of traffic. While we don’t terminate or inspect VXLAN or NVGRE today, we depend on gateways like Arista switches to translate these protocols to VLANs for context. We demonstrated Arista integration as early as last year at our Ignite conference, while BigSwitch SDN integration details are available here.

Have comments, or want to call out your own observations and experiences with SDN? Feel free to comment here or over at SecurityWeek.

← Newer posts Older posts →