Web Application Firewall

Latin ISRM
EFFECTIVE APPLICATION SECURITY STRATEGY FOR
MANAGING ONGOING PCI-DSS 2.0 COMPLIANCE
ASHIT DALAL, PCI-DSS QSA, CRISC, CGEIT, CISM, CISA, CSSA, CPEA
Sr. Manager & Managing Consultant
K3DES LLC,
NJ (USA)
EMAIL: ashit.dalal@k3des.com
October 2011
DISCLAIMER
• The slides in the presentation are my personal
views and experience and based on the
publicly available information and not the
views of or binding on my organization in any
way….
• The presentation is purely for education,
awareness and training through ISACA.
AGENDA
• Brief overview of Application Security and OWASP top 10 Security Threats
• Brief overview of Challenges and Concerns for securing Applications in
conventional Client server and/or Cloud computing / Virtualized
Environment
• Brief Introduction to PCI-DSS (V 2.0) Standard.
• Overview of key requirements under PCI-DSS V 2.0 with regard to
Application Security
• Review of Effective strategy and control measures for securing Applications
in conventional and/or Cloud / Virtualized Environment
• Analysis & Review of various Application Security methods / tools namely
Source Code Review, Web Application Firewall and Web Application
Scanner to comply with PCI-DSS requirements.
• Summary
• Q & A and Discussion
Innocent Code
State of Web Application Security
• A critical discipline within a sound overall IT strategy &
Security practice.
• Existing physical & network security policies, products, point
solutions and controls are not sufficient to meet the security
needs of the enterprise.
• Open Web Application Security Project (OWASP) is dedicated
to helping build secure Web applications.
• Finding the right mix of Experience and Methodology
New realities & requirements for Web
Services Security
• Most security violations come from within the Firewall.
• Vulnerable Applications have contributed to almost 90% of
recent breaches.
• Mission-critical initiatives (e.g. PCI-DSS, PA-DSS) often need
cross-firewall access & integration.
• Ports that were originally intended to pass very specific
protocols are now being used for many purposes.
• XML Web services Simple Object Access Protocol (SOAP)
messages were specifically designed to easily pass through
existing firewalls by being carried out transport protocols like
HTTP, SMTP etc.
Source: XML Web Services Security Forum
Application Security Is the Trend of the
Future
“The biggest vulnerability to a corporation’s network is its
widespread access to its applications. Security has focused
on anti-virus and network security – but the most crucial
part of business transaction is the application and its core
data.”
-- Curtis Coleman, CISSP,
Kick-off of new Application Assurance Department, 2001
3rd Age
2nd Age
1st Age
Age of Application Security
Age of Network Security
Age of Anti-Virus
(Source: OWASP San Jose
7
Chapter)
Business Impact of Application Security Defects
Bad Business
•
On average, there are 5 to 15 defects in every 1,000 lines of code

US Dept. of Defense and the Software Engineering Institute
Slow Business
•
It takes 75 minutes on average to track down one defect. Fixing one
of these defects takes 2 to 9 hours each
 5 Year Pentagon Study
• Researching each of the 4,200 vulnerabilities published by CERT in
2003-2004 for 10 minutes would have required 1 staffer to research
for 17.5 full workweeks or 700 hours
 Intel White paper, CERT, ICSA Labs
Loss of Business
•
A company with 1,000 servers can spend $300,000 to test & deploy
a patch; most companies deploy several patches a week
 Gartner Group
Existing Point Security Solutions are not enough…
• Traditional vulnerability scanners scan web servers but
not web applications.
• Manual Pen test is effective but is not scalable & does
not focus on remediation.
• Traditional Network Firewalls cannot offer protection
against sophisticated attacks targeted on Web
Applications.
• (Web) Application security strategy also needs Riskbased approach comprising, People, Processes and
Technology for effective protection against targeted
attacks
Why isn’t the Web Environment secure?
 SSL and Data-encryption are not enough
 They protect the information during transmission,
but when this data is used by the system it must be
in a readable form
 Odds are the data is not stored in an encrypted
format
 It is surprisingly easy to retrieve data from many
Web-based applications
 Conventional Firewalls are not enough
 Ports 80 and 443 pass completely through the
firewall
(Source: OWASP San Jose Chapter)
10
But, I have a firewall . . .
Source: Jeremiah Grossman, BlackHat 2001
11
OK, but I use encryption . . .
Source: Jeremiah Grossman, BlackHat 2001
12
Your Code is Part of Your Security Perimeter
Billing
Human Resrcs
Directories
APPLICATION
ATTACK
Web Services
Custom Developed
Application Code
Legacy Systems
Databases
Application Layer
Your security “perimeter” has huge
holes at the application layer
App Server
Network Layer
Web Server
Hardened OS
Fi
re
w
al
l
Fi
re
w
al
l
You can’t use network layer protection (firewall, SSL, IDS, hardening)
to stop or detect application layer attacks
Security across entire SDLC
• 80% of vulnerabilities are found in the source code of the
application rather than the Web server or application
configuration. (Ref: HP).
• Traditional approach of having a siloed security team
finishing testing on Web Application and report the
vulnerabilities to the Development teams is being replaced
by more holistic and robust approach that spans across
entire SDLC process.
• It is a team based and risk-driven approach where
Development teams, QA teams and Security teams work
together to build robust Applications.
System Development Lifecycle (SDLC) Security Checkpoints
15
OWASP Top Ten (2010 Edition)
http://www.owasp.org/index.php/Top_10
WHAT DOES OWASP TOP 10 MEAN?
TYPE OF VULNERABILITY
BRIEF DEFINITION
TYPICAL IMPACT
A1 - INJECTION
Tricking an application into including
unintended commands in the data
sent to an interpreter
• Usually severe. Entire database
can usually be read or modified
• May also allow full database
schema, or account access, or even
OS level access
A2- CROSS SITE SCRIPTING
Raw data from attacker is sent to an
innocent user’s browser. Exploiting
user’s trust into a Website
Steal user’s session, steal sensitive
data, rewrite web page, redirect
user to phishing or malware site
A3-BROKEN AUTHENTICATION &
SESSION MGT.
Flaws in Broken Authentication &
Session Management most frequently
involve the failure to protect
credentials and session tokens
through their lifecycle
User accounts compromised or user
sessions hijacked
A4-INSECURE DIRECT OBJECT
REFERENCE
Failure to enforce proper
Authorization
Users are able to access
unauthorized files or data
A5- CROSS SITE REQUEST
FORGERY (CSRF)
An attack where the victim’s browser
is tricked into issuing a command to a
vulnerable web application.
Vulnerability is caused by browsers
automatically. Exploiting Website’s
trust into the User.
• Initiate transactions (transfer
funds, logout user, close account)
• Access sensitive data
• Change account details
TYPE OF VULNERABILITY
BRIEF DEFINITION
TYPICAL IMPACT
WHAT DOES
OWASP TOP
10 MEAN?
A6 –SECURITY
MISCONFIGURATION
Misconfiguration of any
component from the OS up
through the App Server
• Backdoor entry through missing OS or server
patch
• XSS flaw exploits due to missing application
framework patches
• Unauthorized access to default accounts,
application functionality or data, or unused but
accessible functionality due to poor server
configuration
A7- INSECURE CRYPTOGRAPHIC
STORAGE
• Failure to identify all
sensitive data
• Failure to identify all the
places that this sensitive
data gets stored e.g.
Databases, files, directories,
log files, backups, etc.
• Failure to properly protect
this data in every location
• Attackers access or modify confidential or
private information e.g., credit cards, health care
records, financial data etc.
• Attackers extract secrets to use in additional
attacks
• Company embarrassment, customer
dissatisfaction, and loss of trust
• Expense of cleaning up the incident, such as
forensics, sending apology letters, reissuing
thousands of credit cards, providing identity
theft insurance
• Business gets sued and/or fined (e.g. TJ Maxx)
WHAT DOES OWASP TOP 10 MEAN?
TYPE OF VULNERABILITY
BRIEF DEFINITION
TYPICAL IMPACT
A8- FAILURE TO RESTRICT URL
ACCESS
Inadequate enforcement of
proper “authorization”,
along with A4 – Insecure
Direct Object References
• Attackers invoke functions and services
A9-INSUFFICIENT TRANSPORT
LAYER PROTECTION
• Failure to identify all
sensitive data
• Failure to identify all the
places that this sensitive
data is sent e.g.
On the web, to backend
databases, to business
partners and so on.
• Failure to properly protect
this data in every location
•Attackers access or modify confidential or
private information
•Attackers extract secrets to use in additional
attacks
• Company embarrassment, customer
dissatisfaction, and loss of trust
• Expense of cleaning up the incident
Business gets sued and/or fined
A10- UNVALIDATED REDIRECTS
& FORWARDS
Web Application can
include user supplied
parameters in the
destination URL. If they
aren’t validated, attacker
can send victim to a site of
their choice
Redirect victim to phishing or malware
site.
Attacker’s request is forwarded past
security checks, allowing unauthorized
function or data access
they’re not authorized for
• Access other user’s accounts and data
Perform privileged actions
SQL Injection – Example


DB Table


Billing
Directories
Human Resrcs
ATTACK

* FROM
accounts
WHERE
SKU:
SKU:
acct=‘’
OR 1=1-Acct:5424-6066-2134-4334
Acct:4128-7574-3921-0192
’"
Account Summary
Account:
Web Services
HTTP
SQL
response
query

HTTP
request
APPLICATION
Legacy Systems
Databases
Communication
Knowledge Mgmt
E-Commerce
Bus. Functions
Administration
Transactions
Accounts
Finance
Application Layer
Account:
"SELECT
Acct:5424-9383-2039-4029
Acct:4128-0004-1234-0293
1. Application presents a form to
the attacker
Custom Code
2. Attacker sends an attack in
the form data
App Server
3. Application forwards attack to
the database in a SQL query
Firewall
Hardened OS
Firewall
Network Layer
Web Server
4. Database runs query
containing attack and sends
encrypted results back to
application
5. Application decrypts data as
normal and sends results to the
user
Cross-Site Scripting – Example
Attacker sets the trap – update my profile
Victim views page – sees attacker profile
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
2
Administration
Transactions
Attacker enters a
malicious script into a
web page that stores
the data on the server
Application with
stored XSS
vulnerability
Accounts
Finance
1
Custom Code
Script runs inside
victim’s browser with
full access to the DOM
and cookies
3
Script silently sends attacker Victim’s session cookie
CSRF – Example
While logged into vulnerable site,
victim views attacker site
Communication
Knowledge
Mgmt
E-Commerce
Bus. Functions
2
Administration
Transactions
Hidden <img> tag
contains attack
against vulnerable
site
Application with
CSRF vulnerability
Accounts
Finance
1
Attacker sets the trap on some website on the internet
(or simply via an e-mail)
Custom Code
3
<img> tag loaded by
browser – sends GET
request (including
credentials) to
vulnerable site
Vulnerable site sees
legitimate request
from victim and
performs the action
requested
Prevention / Detection of Additional
Vulnerabilities
In addition to OWASP, one needs to look at the following
to have a comprehensive Application Security Strategy:
1) Application runtime configuration
2) Buffer Overflow
3) Web services
4) Malicious code
5) Customized cookies or hidden fields
Source: IBM
23
What is the PCI DSS?
• The Payment Card Industry Data Security Standard
(PCI DSS) is a global security program that was
created to increase confidence in the payment card
industry and reduce risks to PCI Members,
Merchants, Service Providers and Consumers.
https://www.pcisecuritystandards.org/pdfs/pcissc_overview.pdf
Who Must Comply?
PCI data security requirements apply to all merchants and service
providers that store, process or transmit any cardholder data. All
organizations with access to cardholder information must meet the data
security standards.
However, the way in which organizations validate their compliance differs
based on whether they are merchants or service providers and on
specific validation requirements defined by each credit card brand. Each
of the five major credit card companies has its own set of validation
requirements.
Information regarding service provider levels and validation requirements
can be obtained from each individual credit card company’s Web site.
The security requirements apply to all system components, network
components, servers or applications included in, or connected to, the
processing of cardholder data.
25
Who does PCI DSS apply to?
• Any entity that stores, process and/or transmits
cardholder data must comply with the PCI Data
Security Standard (DSS). Entities may include, but
are not limited to, merchants and service providers.
• Applies to:
–
–
–
–
–
–
–
–
Retail (online & brick & mortar)
Hospitality (restaurants, hotel chains, etc.)
Transportation (i.e. airlines, car rental, etc.)
Financial Services (banks, credit unions, card processors, brokerages, insurance, etc.)
Energy (Oil, Gas, Utilities, etc),
Healthcare/Education (hospitals, universities)
Government (Federal, Provincial, Municipal)
Not-For-Profit Organizations (Red Cross, churches, etc)
Key PCI DSS Requirements
Build and Maintain a Secure Network
1.
Install and maintain a firewall configuration to protect cardholder data
2.
Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
3.
Protect stored cardholder data
4.
Encrypt transmission of cardholder data sent across open, public networks
Maintain a Vulnerability Management Program
5.
Use and regularly update anti-virus software
6.
Develop and maintain secure systems and applications
Implement Strong Access Control Measures
7.
Restrict access to cardholder data by business need-to-know
8.
Assign a unique ID to each person with computer access
9.
Restrict physical access to cardholder data
Regularly Monitor and Test Networks
10.
Track and monitor all access to network resources and cardholder data
11.
Regularly test security systems and processes
Maintain an Information Security Policy
12.
Maintain a policy that addresses information security – Connected Entities and Contracts
PCI DSS Ver. 1.1
Three Components to Compliance Program
• Compliance: The set of criteria to achieve compliance with
the payment brand compliance program.
– All payment brands require compliance with the PCI DSS.
• Validation: The actions that an entity must take to validate
that they are compliant.
– Validation requirements vary by payment brand and
merchant/service provider level
• Reporting: The method of reporting the validation of
compliance to the acquirer or payment brand
– Reporting requirements vary by payment brand and
merchant/service provider level
PCI Compliance – Trends and Tips
PCI is not about securing sensitive data, it’s
about eliminating data altogether.
John Kindervag, Forrester Analyst and former QSA
PCI Compliance – Trends and Tips
“PCI SWALLOWS ITS OWN TAIL”
• “I’m concerned that as long as the payment card industry is
writing the standards, we’ll never see a more secure
system,” (Rep. Bennie) Thompson said. “We in Congress must
consider whether we can continue to rely on industrycreated standards, particularly if they’re inadequate to
address the ongoing threat.”
•
http://information-security-resources.com/2009/04/01/payment-card-industry-swallows-itsown-tail
Recent Credit/ Debit Card breaches
•
•
•
•
Citibank (June 2011)
Sony Play station (May 2011)
Michael’s Store (Debit Cards) (May 2011)
T. J. Max (January 2007) –45 Million
Customers
• Heartland Systems, Princeton, NJ (Jan.
2009)
• Hannaford Brothers (March 2008) – 4.2
Million Customers
• Card System Solutions (2005) – 40
Million Customers
PCI-DSS requirements for developing &
maintaining secure systems & applications
Section 6 of PCI-DSS (Ver: 2.0) has key requirements for
developing & maintaining secure systems & applications:
6.1 Implement an effective Patch Management process for protection
from known vulnerabilities.
6.2 Establish process to identify & assign a risk ranking to newly
discovered security vulnerabilities. (e.g. OWASP Top 10).
6.3 Develop software applications in accordance with PCI-DSS and
industry based best practices. Incorporate Information Security
through out the SDLC Process.
6.4 Implement an effective Change Management Process
6.5 Develop Applications based on Secure Coding guidelines. Prevent
common coding vulnerabilities in SDLC Processes.
PCI-DSS requirements for developing &
maintaining secure systems & applications
6.6 For public-facing Web applications, address new threats &
vulnerabilities on an on-going basis & ensure these
applications are protected from known vulnerabilities by:
• Conducting Vulnerability assessment (manual or by using
automated tools) at least annually or after any changes.
OR
• Installing a Web-application Firewall in front of public-facing
web applications.
Identified Vulnerabilities under Section 6.5 of PCI-DSS
Vulnerability
Testing Procedure / Countermeasure
Injection Flaws (e.g. SQL Injection, OS Validate input to verify user data cannot modify
Command Injection, LDAP Injection
meaning of commands & queries.
etc.)
Buffer overflow
Validate buffer boundaries & truncate input
strings
Insecure cryptographic storage
Prevent cryptographic flaws
Insecure communications
Properly encrypt all authenticated & sensitive
communications
Improper error handling
Do not leak information via error messages
Identify all High Vulnerabilities as
required under Section 6.2
Identification of all “High” vulnerabilities. This is
currently the best practice but becoming a
requirement from June 30, 2012 onwards
Cross-site Scripting
Validate all parameters before inclusion, utilize
context-sensitive escaping etc.
Identified Vulnerabilities under Section 6.5 of PCI-DSS
Vulnerability
Testing Procedure / Countermeasure
Improper Access Control such as
Proper Authentication of users and sanitize
Insecure Object References, failure to input. Do not reveal internal object references
restrict URL access & Directory
to users.
traversal
Cross-site request Forgery (CSRF)
Do not reply on authorization credentials and
tokens automatically submitted through or by
browsers.
PCI-DSS Requirement – Section 6.6
Requirement 6.6 (as of June 30, 2008)
 Web application firewall or code review?
 It’s your choice, but should they both be
required?
Payment Application (PA-DSS)
 Time for another acronym … Payment Application Data Security Standard
(PA-DSS)
 PA-DSS, originally Visa’s PABP program, is targeted at payment app vendors
 PA-DSS applies to the payment application software/hardware only
 Just because the application is compliant does not mean your
systems are compliant
 PCI DSS applies to merchant networks & service providers
Standalone
Terminal
POS System
Best Practices for Secure Code Development
• Develop Secure Code
– Follow the best practices in OWASP’s Guide to Building Secure Web Applications
• http://www.owasp.org/index.php/Guide
– Use OWASP’s Application Security Verification Standard as a guide to what an
application needs to be secure
• http://www.owasp.org/index.php/ASVS
– Use standard security components that are a fit for your organization
• Use OWASP’s ESAPI as a basis for your standard components
• http://www.owasp.org/index.php/ESAPI
• Review Your Applications
– Have an expert team review your applications
– Review your applications following OWASP Guidelines
• OWASP Code Review Guide:
http://www.owasp.org/index.php/Code_Review_Guide
• OWASP Testing Guide:
http://www.owasp.org/index.php/Testing_Guide
CoBIT & Relevant Application Security Controls
Plan and
Organize
PO4 Define the IT Processes, Organization & relationships
PO8 Manage Quality
PO 9 Assess & Manage IT Risk
Acquire &
Impleme
nt
AI 2 Acquire & maintain Application software
AI 6 Manage changes (Change Management)
AI 7 Install & accredit Solution & Changes
Deliver &
Support
DS 5 Manage System Security
DS 9 Manage the Configuration
Monitor &
Evaluate
MI 3 Ensure compliance with external requirements
(e.g. PCI-DSS)
(Vulnerability) Prevention v/s (Threat) Detection
From PCI-DSS standpoint, Application Security Strategy can be
deigned and implemented based on two main approaches:
1) Vulnerability Prevention – Pro-active Prevention approach
2) Threat Detection – Reactive Detection approach
No Application security strategy can be considered effective
without having a right balance of two approaches specific to
Each organization according to threat, exposure and TCO
considerations .
Major Techniques / Tools for implementing
effective Application Security Strategy
• SOURCE CODE ANALYSIS- Preventive measure
Source Code Analysis tools are designed to analyze the source code and /or complied
version of code in order to help find security flaws.
• WEB APPLICATION FIREWALL- Detective measure
A Web Application Firewall is a form of firewall which controls input, , output, and/or
Access from, to, or by an application or service. It operates by monitoring and
Potentially blocking the input, output, or system service calls which do not meet the
Configured policy of the firewall.
• WEB APPLICATION SCANNER-Primarily Detective /
(but can also be used as Preventive measure)
A Web Application Scanner is program which communicates with a web application
through the web front-end in order to identify potential security vulnerabilities in the
web application and architectural weaknesses. It performs a black-box test.
EFFECTIVENESS OF VARIOUS TOOLS
TYPE OF VULNERABILITY SOURCE CODE
ANALYSIS
WEB APPLICATION
FIREWALL
WEB APPLICATION
SCANNER
A1 - INJECTION
EXCELLENT
GOOD
FAIR
A2- CROSS SITE SCRIPTING
EXCELLENT
GOOD
GOOD
A3-BROKEN
AUTHENTICATION &
SESSION MGT.
NOT EFFECTIVE ON
ITS OWN
NOT EFFECTIVE ON
ITS OWN
NOT EFFECTIVE ON ITS
OWN
A4-INSECURE DIRECT
OBJECT REFERENCE
EXCELLENT
GOOD
GOOD
A5- CROSS SITE REQUEST
FORGERY (CSRF)
LIMITED UTILITY
LIMITED UTILITY
FAIR (NEEDS TO BE
USED WITH MANUAL
PEN TEST)
EFFECTIVENESS OF VARIOUS TOOLS (Contd..)
TYPE OF VULNERABILITY SOURCE CODE
ANALYSIS
WEB APPLICATION
FIREWALL
WEB APPLICATION
SCANNER
A6 –SECURITY
MISCONFIGURATION
GOOD
GOOD
EXCELLENT
A7- FAILURE TO RESTRICT
URL ACCESS
FAIR
FAIR
FAIR
A8-INSECURE
CRYPTOGRAPHIC STORAGE
GOOD
NOT EFFECTIVE ON
ITS OWN
NOT EFFECTIVE ON
ITS OWN
A9-INSUFFICIENT
TRANSPORT LAYER
PROTECTION
GOOD
GOOD
GOOD
A10- UNVALIDATED
REDIRECTS & FORWARDS
FAIR
GOOD
FAIR
EFFECTIVENESS OF VARIOUS TOOLS (Contd..)
TYPE OF VULNERABILITY SOURCE CODE
ANALYSIS
WEB APPLICATION
FIREWALL
WEB APPLICATION
SCANNER
B1-APPLICATION RUNTIME
CONFIGURATION
FAIR
FAIR
EXCELLENT
B2-BUFFER OVERFLOW
EXCELLENT
FAIR
FAIR
B3-WEB SERVICES
GOOD
GOOD
NOT EFFECTIVE
B4- MALICIOUS CODE
EXCELLENT
NOT GOOD
NOT GOOD
B5- CUSTOMIZED COOKIES
/ HIDDEN FIELDS
EXCELLENT
EXCELLENT
EXCELLENT
Why Use Web Application Firewalls?
1. Web applications deployed are generally insecure and
conventional Firewalls do not provide adequate
protection.
2. Developers should, of course, continue to strive to build
better/more secure software. But in the meantime,
System Admins must also support “Defence-in-Depth”
approach.
3. Insecure applications aside, WAFs are an important
building block in every HTTP network as they serve as
an excellent detection & monitoring tool to support
“Preventive Controls” such as Source Code Analyzer.
Source: OWASP
45
Network Firewalls Do Not Work For
HTTP
Firewall
Application
Web
Client
Web
Server
HTTP Traffic
Port 80
Source: OWASP
46
Application
Database
Server
TYPICAL CLOUD BASED ENVIRONMENT
SUMMARY : What constitutes an effective
Application Security Strategy for PCI-DSS compliance
1.
2.
Adoption of Risk-based, holistic & “Defence-in-Depth” approach.
Effective implementation of key policies, procedures and processes (e.g. Change
Management, Patch Management etc. )
Use of Frameworks and Industry Standards and best practices like CoBIT 4.1, ISO
27001: 2005 and so on to ensure effective implementation of general IT Controls
and IT Assurance framework .
Deploy Industry best practices for Secure Code development, Testing, Code Review
e.g.
3.
4.
–
–
–
5.
Deploy tools (as Preventive & Detective controls) like:
–
–
–
6.
7.
OWASP
XML Web Security Services Forum (XWSS)
Common Weakness enumeration (CWE) 2011 / SAN Top 25
Source Code Analyzers
Web Application Firewall
Web Application Scanner
Conduct periodic Pen Test
On-going training and awareness on Application Security
48
Questions
49
CONTACT:
Contact:
ASHIT DALAL, PCI-DSS QSA, CRISC, CGEIT, CISA,CISM, CPEA, CSSA
Six Sigma Black Belt
Sr. Manager & Managing Consultant
K3 DES LLC,
NJ (USA)
T.NO: 609-575-4645 (USA)
+91-98191-18590 (India)
Email: ashit.dalal@k3des.com
50