Next Generation FWs Against Modern Malware and Threads

Hakan Unsal – Technical Security Consultant

Tunc Cokkeser – Regional Sales Manager

The Strategic Role of Modern Malware

Infection

Escalation

Remote Control

Malware Industry: 1 Trillion Dollar

• A new unknown MALWARE in each 1,5 sec

• Hidden in SSL or SSH tunneld / encrypted traffic

• Resource consuming MALWARE

Industry Challenges in Controlling Malware

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 3 |

Unreliable enforcement•Sandboxes lack enforcement, while enforcement points lack sandbox intelligence•Lack of outbound traffic controls•Lack of actionable information

Inability to recognize files as malware

•Targeted malware•New and refreshed malware•Long windows to protection

Infecting files are hidden• Inside applications•Encrypted traffic, proxies•Non-standard ports•Drive-by-downloads

Applications Have Changed; Firewalls Have Not

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 4 |

Need to restore visibility and control in the firewall

BUT…applications have changed

• Ports ≠ Applications

• IP Addresses ≠ Users

• Packets ≠ Content

More than %67 of all applications use port 80 and 443

Why we need a NGFW?Applications Carry Risk

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 5 |

Applications can be “threats”• P2P file sharing, tunneling

applications, anonymizers, media/video

Applications carry threats• Qualys Top 20 Vulnerabilities –

majority result in application-level threats

Applications & application-level threats result in major breaches – RSA, Comodo, FBI

Why we need a NGFW?Traditional Solutions are no longer a solution...

• “More stuff” doesn’t solve the problem

• Firewall “helpers” have limited view of traffic

• Complex and costly to buy and maintain

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 6 |

Internet

• Putting all of this in the same box is just slow

Why we need a NGFW?Control Must Be In The Firewall

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 7 |

• Port PolicyDecision

• App Ctrl PolicyDecision

Application Control as an Add-on• Port-based FW + App Ctrl (IPS) = two policies • Applications are threats; only block what you

expressly look for

Implications • Network access decision is made with no

information• Cannot safely enable applications

IPS

Applications

Firewall

PortTraffic

Firewall IPS

• App Ctrl PolicyDecision

• Scan Applicationfor Threats

Applications

ApplicationTraffic

NGFW Application Control • Application control is in the firewall = single policy• Visibility across all ports, for all traffic, all the time

Implications • Network access decision is made based on

application identity • Safely enable application usage

How a NGFW Should Be!!!The Right Answer: Make the Firewall Do Its Job

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 8 |

New Requirements for the Firewall

1. Identify applications regardless of port, protocol, evasive tactic or SSL

2. Identify users regardless of IP address

3. Protect in real-time against threats embedded across applications

4. Fine-grained visibility and policy control over application access / functionality

5. Multi-gigabit, in-line deployment with no performance degradation

How a NGFW Should Be!!!Palo Alto Networks Controls the Threat Vector

• Simple, yet powerful control of 900+ applications – block, or allow but scan for threats

How a NGFW Should Be!!!Negative Security Method No Longer Works...

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 10 |

How a NGFW Should Be!!!Positive Security Methodology...

»The ever-expanding universe of applications, services and threats

»Traffic limited to approved business use cases based on App and User

»Attack surface reduced by orders of magnitude

»Complete threat library with no blind spots

Bi-directional inspection

Scans inside of SSL

Scans inside compressed files

Scans inside proxies and tunnels

Only allow the apps you need

Safely enable the applications relevant

to your business

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 11 |

How a NGFW Should Be!!!“Secure Enablement’’

• ‘Secure Enablement’’ - Block – e.g. – all P2P applications- Allow - but scan for threats- Allow - but limit app users- Allow - but limit app functions- Allow - but limit apps in a session- Allow - but limit access time- Allow - but shape (QoS)

• Low • High

• Network Control

How a NGFW Shoud Be!!!Application Identification Algorithm

How a NGFW Should Be!!!BitTorrent

How a NGFW Should Be!!!BitTorrent: As Seen by Security Infrastructure

How a NGFW Should Be!!!Realtime Monitoring for Applications, Users & Content

• Application Command Center (ACC)- Uygulama, URL, tehditler ve data

filtreleme aktivitelerini görüntüler

© 2010 Palo Alto Networks. Proprietary and Confidential.Page 16 | Facebook için Filtre oluştur Facebook ve Ginger kullanıcısı

İçin Filtre oluşturSadece Ginger kullanıcısını görüntülemek için

Facebook’u kaldır

How a NGFW Should Be!!!WildFire Architecture

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 17 |

• Unknown files

comming from

Internet cloud

Compare to Known Files

Sandbox Environment

Signature Generator

Admin Web Portal

• FW sends

the unknown file to Wildfire Cloud

• New signitures

are updated on all FWs.

How a NGFW Should Be!!!A Realtime Application Identification Throughput

• L3/L4 UDP Packet throupghput is no longer reflects your requirements!!!

• APP - ID Application Identification Enabled Throughput is important for you!!!

• L7 Throughput should be considered

• No Acceptance for Dramatic Performance Decrease !!!

UDP Big Packet "Real World" Perimeter "Real World" Core0

2000

4000

6000

8000

10000

12000

XXX Gbps

X Gbps

XXx Mbps

How a NGFW Should Be!!!Single-Pass Parallel Processing™ (SP3) Architecture

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 19 |

Single Pass• Operations once per

packet

- Traffic classification (app identification)

- User/group mapping

- Content scanning – threats, URLs, confidential data

• One policy

Parallel Processing• Function-specific parallel

processing hardware engines

• Separate data/control planes

• Up to 20Gbps, Low Latency

© 2010 Palo Alto Networks. Proprietary and Confidential

How a NGFW Should Be!!!Multi Gigs realtime High Throughput

• 80 Gbps switch fabric interconnect

• 20 Gbps QoS engine

Signature Match HW Engine• Stream-based uniform sig.

match• Vulnerability exploits (IPS),

virus, spyware, CC#, SSN, and more

Security Processors• High density parallel

processing for flexible security functionality

• Hardware-acceleration for standardized complex functions (SSL, IPSec, decompression)

20Gbps

Network Processor• 20 Gbps front-end network

processing• Hardware accelerated per-

packet route lookup, MAC lookup and NAT

10Gbps

Data PlaneSwitch Fabric

10Gbps

... ......

QoS

Flow control

Route, ARP, MAC

lookup

NATSwitchFabric

Signature Match

Signature Match

SSL IPSec De-Compress. SSL IPSec De-

Compress.SSL IPSec De-Compress.

CPU12

CPU1

CPU2

CPU12

CPU1

CPU2

CPU12

CPU1

CPU2

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

RAM

• Quad-core mgmt• High speed logging

and route update• Dual hard drives

Control Plane

Core 1RAM

RAM

SSD

SSD

Core 2

Core 3 Core 4

Technology Sprawl & Creep Are Not The Answer

• “More stuff” doesn’t solve the problem

• Firewall “helpers” have limited view of traffic

• Complex and costly to buy and maintain

© 2011 Palo Alto Networks. Proprietary and Confidential.Page 21 |

Internet

• Putting all of this in the same box is just slow