Transcript Palo Alto Networks

Next Generation FWs Against
Modern Malware and Threads
Hakan Unsal – Technical Security Consultant
Tunc Cokkeser – Regional Sales Manager
The Strategic Role of Modern Malware
•
A new unknown MALWARE in each 1,5 sec
Hidden in SSL or SSH tunneld / encrypted traffic
•
Resource consuming MALWARE
Infection
Escalation
Remote Control
Malware Industry: 1 Trillion Dollar
Industry Challenges in Controlling Malware
Infecting files are
hidden
Inability to recognize
files as malware
•Inside applications
•Encrypted traffic, proxies
•Non-standard ports
•Drive-by-downloads
•Targeted malware
•New and refreshed malware
•Long windows to protection
Unreliable enforcement
•Sandboxes lack enforcement, while
enforcement points lack sandbox intelligence
•Lack of outbound traffic controls
•Lack of actionable information
Page 3 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Applications Have Changed; Firewalls Have Not
More than %67 of all applications
use port 80 and 443
BUT…applications have changed
• Ports ≠ Applications
• IP Addresses ≠ Users
• Packets ≠ Content
Need to restore visibility and control in the firewall
Page 4 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Why we need a NGFW?
Applications Carry Risk
Applications can be “threats”
• P2P file sharing, tunneling
applications, anonymizers,
media/video
Applications carry threats
• Qualys Top 20 Vulnerabilities –
majority result in applicationlevel threats
Applications & application-level threats result in major breaches – RSA, Comodo, FBI
Page 5 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Why we need a NGFW?
Traditional Solutions are no longer a solution...
Internet
• “More stuff” doesn’t solve the problem
• Firewall “helpers” have limited view of traffic
• Complex and costly to buy and maintain
• Putting all of this in the same box is just slow
Page 6 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Why we need a NGFW?
Control Must Be In The Firewall
Application Control as an Add-on
Traffic
• Port-based FW + App Ctrl (IPS) = two policies
Port
Firewall
IPS
Applications
•Port Policy
Decision
•App Ctrl Policy
Decision
• Applications are threats; only block what you
expressly look for
Implications
• Network access decision is made with no
information
• Cannot safely enable applications
NGFW Application Control
• Application control is in the firewall = single policy
Traffic
Application
• Visibility across all ports, for all traffic, all the time
Implications
• Network access decision is made based on
application identity
• Safely enable application usage
Page 7 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Firewall
IPS
Applications
•App Ctrl Policy
Decision
•Scan Application
for Threats
How a NGFW Should Be!!!
The Right Answer: Make the Firewall Do Its Job
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
Page 8 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
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...
Page 10 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
How a NGFW Should Be!!!
Positive Security Methodology...
Only allow the
apps you need
» Traffic limited to
approved business
use cases based on
App and User
» Attack surface
reduced by orders of
magnitude
» The ever-expanding
universe of applications,
services and threats
Page 11 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
Safely enable the
applications relevant
to your business
» Complete threat library with no
blind spots
 Bi-directional inspection
 Scans inside of SSL
 Scans inside compressed
files
 Scans inside proxies and
tunnels
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
•Network
Control
- Allow - but limit app functions
- Allow - but limit apps in a session
- Allow - but limit access time
- Allow - but shape (QoS)
•Low
•High
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
Page 16 | © 2010 Palo Alto Networks. Proprietary and Confidential.
Sadece Ginger kullanıcısını görüntülemek için
Facebook
için Filtre oluştur Facebook ve Ginger kullanıcısı
İçin Filtre oluştur
Facebook’u kaldır
How a NGFW Should Be!!!
WildFire Architecture
Compare to Known Files
Sandbox Environment
Signature Generator
Admin Web Portal
•Unknown
files comming
from Internet
cloud
Page 17 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
•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 !!!
12000
10000
XXX Gbps
8000
6000
X Gbps
4000
XXx Mbps
2000
0
UDP Big Packet
"Real World" Perimeter
"Real World" Core
How a NGFW Should Be!!!
Single-Pass Parallel Processing™ (SP3) Architecture
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
Page 19 |
© 2011 Palo Alto Networks. Proprietary and Confidential.
How a NGFW Should Be!!!
Multi Gigs realtime High Throughput
• Quad-core mgmt
• High speed logging
and route update
• Dual hard drives
RAM
Signature Match HW Engine
• Stream-based uniform sig.
match
• Vulnerability exploits (IPS),
virus, spyware, CC#, SSN, and
more
RAM
RAM
Signature
Match
RAM
Signature
Match
RAM
RAM
RAM
RAM
RAM
Core 1 Core 2
10Gbps
10Gbps
RAM
SSD
Core 3 Core 4
CPU
1
CPU ... CPU
2
12
SSD
Control Plane
• 80 Gbps switch fabric
interconnect
• 20 Gbps QoS engine
QoS
Switch
Fabric
SSL
IPSec
RAM
RAM
DeCompress.
Security Processors
• High density parallel
processing for flexible
security functionality
• Hardware-acceleration for
standardized complex
functions (SSL, IPSec,
decompression)
Switch Fabric
© 2010 Palo Alto Networks. Proprietary and Confidential
CPU
1
CPU ... CPU
2
12
SSL
IPSec
RAM
RAM
DeCompress.
CPU
1
SSL
CPU ... CPU
2
12
IPSec
RAM
RAM
DeCompress.
20Gbps
Flow
control
Route,
ARP,
MAC
lookup
Data Plane
NAT
Network Processor
• 20 Gbps front-end network
processing
• Hardware accelerated perpacket route lookup, MAC
lookup and NAT
Technology Sprawl & Creep Are Not The Answer
Internet
• “More stuff” doesn’t solve the problem
• Firewall “helpers” have limited view of traffic
• Complex and costly to buy and maintain
• Putting all of this in the same box is just slow
Page 21 |
© 2011 Palo Alto Networks. Proprietary and Confidential.