Home > Take5 > Take5 (Episode #7) – Five Questions for Nir Zuk, Founder & CTO Palo Alto Networks

Take5 (Episode #7) – Five Questions for Nir Zuk, Founder & CTO Palo Alto Networks

November 26th, 2007 Leave a comment Go to comments

It’s been a while since I’ve done a Take5 and this seventh episode interviews Nir Zuk, Founder & CTO of up-start "next-generation firewall" company Palo Alto Networks

There’s been quite a bit of hubbub lately about PAN and I thought I’d see what all the frothing was about.  I reached out to Nir and sent him a couple of questions via email which he was kind enough to answer.  PAN is sending me a box to play with so we’ll see how well it holds up on the Rack.  I’m interested in seeing how this approach addresses the current and the next generation network security concerns.

Despite my soapbox antics regarding technology in the security space, having spent the last two years at a network security startup put me at the cutting-edge of some of the most unique security hardware and software in the business and the PAN solution has some very interesting technology and some very interesting people at its core.

If you’ve used market-leading security kit in your day, you’ve probably appreciated some of Nir’s handywork:

First a little background on the victim:


Nirzuk_2
Nir Zuk brings a wealth of network security expertise and industry
experience to Palo Alto Networks. 

Prior to co-founding Palo Alto
Networks, Nir was CTO at NetScreen Technologies, which was acquired by
Juniper Networks in 2004.

Prior to NetScreen, Nir was co-founder and
CTO at OneSecure, a pioneer in intrusion prevention and detection
appliances.  Nir was also a principal engineer at Check Point Software
Technologies and was one of the developers of stateful inspection
technology.


Just to reiterate the Take5 ground-rules: I have zero interest in any
of the companies who are represented by the folks I interview, except
for curiosity.  I send the questions via email and what I get back, I post.  There are no clarifying attempts at messaging or do-overs.  It’s sort of like live radio, but without sound…

Questions:

1) Your background in the security space is well known and as we take a
look out at the security industry and the breadth of technologies and
products balanced against the needs of the enterprise and service
providers, why did you choose to build another firewall product?

Don't we have a mature set of competitors in this space?  What need is
Palo Alto Networks fulfilling?  Isn't this just UTM?


The reason I have decided to build a new firewall product is quite
similar to the reasons Check Point (one of my previous employers)
decided to build a new firewall product back in the early 90's when
people where using packet filters embedded in routers - that reason
being that existing firewalls are ineffective. Throughout the years,
application developers have learnt how to bypass existing firewalls
using various techniques such as port hopping, tunneling and encryption.
Retrofitting existing firewalls, which use ports to classify traffic,
turned out to be impossible hence a new product had to be developed from
the ground up.

2) As consolidation of security technologies into less boxes continues
to heat up, vendors in the security space add more and more
functionality to their appliances so as not to be replaced as the
box-sprinkling madness continues.  Who do you see as a competitive
threat and who do you see your box replacing/consolidating in the long
term?


I think that a more important trend in network security today is the
move from port-centric to application-centric classification
technologies. This will make most of the existing products obsolete,
similar to the way stateful inspection has made its predecessors
disappear from the world... As for device consolidation, I think that
existing firewall architectures are too old to support real
consolidation, which today is limited to bolting multiple segregated
products on the same device with minimal integration. A new
architecture, which allows multiple network security technologies to
share the same engines, has to emerge before real consolidation happens.
The Palo Alto Networks PA-4000 series is, I believe, the first device to
offer this kind of architecture.

3) The PA-4000 Series uses some really cutting-edge technologies, can
you tell us more about some of them and how the appliance is
differentiated from multi-core x86 based COTS appliances? Why did you go
down the proprietary hardware route instead of just using standard Intel
reference designs and focus on software?

Intel CPUs are very good at crunching numbers, running Excel
spreadsheets and for playing high-end 3D games. They are not so good at
handling packets. For example, the newest quad core Intel CPU can
handle, maybe, 1,500,000 packets per second which amounts to about 1
Gbps with small packets. A single network processor, such as the one of
many that we have in the PA-4000 series, can handle 10 times that -
15,000,000 packets per second. Vendors that claim 10 Gbps throughput
with Intel CPUs, do so with large packet sizes which do not represent
the real world.


4) Your technology focuses on providing extreme levels of application
granularity to be able to identify and control the use of specific applications.   

Application specificity is important as more and more applications use well
known ports (such as port 80) encryption or other methods to obfuscate
themselves to bypass firewalls.  Is this going deep enough?  Don't you need
to inspect and enact dispositions at the content level; after all, it's the
information that's being transmitted that is important.


Inspection needs to happen at two levels. The first one is used to
identify the application. This, usually, does not require going into the
information that's being transmitted but rather merely looking at the
enclosing protocol. Once the application is identified, it needs to be
controlled and secured, both of which require much deeper inspection
into the information itself. Note that simply blocking the application
is not enough - applications need to be controlled - some are always
allowed, some are always blocked but most require granular policy. The
PA-4000 products perform both inspections, on two different
purpose-built hardware engines.

5)  You've architected the PA-4000 Series to depend upon signatures and
you don't use behavioral analysis or behavioral anomaly detection in the
decision fabric to determine how to enact a disposition.  Given the
noise associated with poorly constructed expressions based upon
signatures in products like IDS/IPS systems that don't use context as a
decision point, are you losing anything by relying just on signatures?


The PA-4000 is not limited to signature-based classification of
applications. It is using other techniques as well. As for
false-positive issues, these are usually not associated with traffic
classification but rather with attack detection. Generally, traffic
classification is a very deterministic process that does not suffer from
false positives. As for the IDS/IPS functionality in the PA-4000 product
line, it is providing full context for the IDS/IPS signatures for better
accuracy but the most important reason as to why the PA-4000 products
have better accuracy is because Palo Alto Networks is not a pure IPS
vendor and therefore does not need to play the "who has more signatures"
game which leads to competing products having thousands of useless
signatures that only create false positives.

BONUS QUESTION:

6)  The current version of the software really positions your solution as
a client-facing, forward proxy that inspects outbound traffic from an end-user
perspective.   

Given this positioning which one would imagine is done mostly at a "perimeter"
choke point, can you elaborate on adding features like DLP or NAC?  Also, if
you're at the "perimeter" what about reverse proxy functionality to inspect
inbound traffic to servers on a DMZ?


The current shipping version of PAN-OS provides NAC-like functionality
with seamless integration with Active Directory and domain controllers.
DLP is not currently a function that our product provides even though
the product architecture does not preclude it. We are evaluating adding
reverse proxy functionality in one of our upcoming software releases.

Categories: Take5 Tags:
  1. Mark
    November 27th, 2007 at 12:20 | #1

    Chris, thx for this Q&A.

  2. November 28th, 2007 at 09:07 | #2

    Check out how this is being torn to shreds by MJR on firewall-wizards list :-)

  3. November 28th, 2007 at 09:50 | #3

    Anton:
    You mean the thread about stateful inspection?
    This one? http://seclists.org/firewall-wizards/2007/Nov/010
    > With respect to the "stateful packet inspection" garbage;
    > it's computer security's equivalent of homeopathy or
    > accupuncture: people like it because it makes them
    > feel better. It's a placebo.
    /Hoff

  4. November 28th, 2007 at 14:19 | #4

    I've looked at PAN. Seems like their major breakthrough is being smart enough to do on-the-fly SSL interception and apply signatures to it. The rest of the stuff seems like things that are done today, to a certain extent, by deep inspection and intrusion prevention products. My question would be how well they can adapt to new protocols and what the effect on performance is, unless they are going strictly with signatures.

  5. November 28th, 2007 at 16:22 | #5
  6. Kyle C. Quest
    November 29th, 2007 at 09:23 | #6

    MJR comments are funny… because they are actually true :-)
    There are two things that they PAT is going with:
    1. Protocol identification based on protocol signatures
    and not ports.
    2. When SSL traffic is detected they use their SSL proxy.
    Non-port-based protocol identification is something that I've already seen. At my old company we worked with this Swedish company sold that kind of technology. Then there's also a little company called Cymphonix, who also do dynamic protocol identification based on protocol fingerprinting. There's even an open source IDS that does that (it's called Bro IDS).

  7. January 8th, 2008 at 21:09 | #7

    A number of comments – some made by other people on the blog:
    1) Port-independent app protocol detection is not new – the Fidelis XPS is a commercial product that has done it for 3 years
    2) I don't believe that using network processors is the best approach since:
    a) you miss out on all the economy of scale and power of Intel
    b) the software development for a NPU is a lot more difficult to write and maintain – which means that PAL will be by definition far less responsive to changes in attack patterns than Intel Linux based products. A good example is Webmail – where the app protocols can change almost daily.
    c) The performance differential between a NPU and Intel CPU is highly overrated – if you know how to write kernel level and real time network software properly you can deliver enough performance to keep up. I will grant that for encrypt/decrypt operations an NPU is essential at these speeds
    3) I don't buy deep packet inspection, if you want to be able to detect content properly than you have to do full session reassembly – and my question to Nir is – Do you guys do full session reassembly? Because if you don't then forget about DLP in your product roadmap. It won't work
    Danny

  1. No trackbacks yet.