web app sec roadmap

Web Application SecurityRoadmap

Joe [email protected]

CyberlocksmithApril 2008

Version 0.9

• Web application security is still very much in it’s infancy.

• Traditional ‘operations’ teams do not understand web applicationsecurity risk and are ill-equipped to defend against web applicationthreats.

• Many companies are wrestling with web application security andassigning ownership of the entire web application security effort toone person but these companies are still trying to figure out wherethis person fits into the organization.

• Security ‘turf battles’ are inevitable in these situations.

• There is no clear separation between where web application securitystops and traditional operations security begins.

Background

• Your company does not fully understand how to manage webapplication security risk.

• You have been assigned ownership of web application security and youare wrestling with prioritizing and scoping the challenges ahead ofyou.

• You are engaged in a security ‘turf battle’ with your operationssecurity team and your operations security team does not adequatelyunderstand web application security risks.

• You need help proactively managing expectations for securing yourweb applications.

Audience for this presentation

• Let you know that you are not alone and that many other securityprofessionals are wrestling with similar web application securityconcerns and issues.

• Offer a roadmap for your next steps that will build the confidence ofyour peers and management in your abilities to manage webapplication security risk.

• Help you to proactively manage the expectations of your seniormanagement.

• Ensure that you understand the current industry ‘best practices’ forsecuring web applications.

• Help you to succeed.

Purpose of this presentation

This presentation is intended to assist Security professionals by offeringobjective guidance for deploying effective Web Application Securitysolutions that are consistent with current industry ‘Best Practices’.

This Web Application Security Roadmap will include approximate timeand expense estimates pulled from a combination of personalexperiences and informal colleague discussions. However, your mileagemay vary.

Vendor references are supplied as reference and are intended to beobjective and informative.

This presentation is independent of any official vendor affiliation.

No vendor was harmed during the making of this presentation.

Disclaimer

• Find Web Application vulnerabilities

• Address Web Application vulnerabilities

• Monitor/detect Web Application compromise attempts

• Decide upon threat classification framework and scoring model

• Develop Web Application Incident Response plan

• Scope/prioritize internal Web Application specific projects

• Proactively increase security awareness

• Threat Modeling (TM) and Data Flow Diagrams (DFDs)

• Manual Code Review (outside expert)

• Other possible Roadmap items to consider

Web Application Security Roadmap Objectives

______________________________________________________

Build a foundationInternal projects

• Automated component

• Choose the automated web application security assessment tool that worksbest with your web application technology.

• Make sure you are addressing all internet facing web application exposure.

• Deploy Static Source code analysis tool to scan for security vulnerabilitieswithin the source code.

Find Web Application vulnerabilities

• Manual component

• Manual web application security assessment is required to compliment theautomated assessment above.

• Work to better educate manual assessment teams of the way your webapplication functions so they can better detect logic flaws and other pieceslikely to be missed by automated scans.

• Integrate both peer code review and manual review of the static sourcecode analysis results into your development life cycle.

Build a foundation

Web Application Security Assessment vendors

• AppScan - Watchfire (www.watchfire.com)

• Core Impact - Core Security (www.coresecurity.com)

• Hailstorm - Cenzic (www.cenzic.com)

• NTOSpider - NT OBJECTives (www.ntobjectives.com)

• WebInspect - SPI Dynamics (www.spydynamics.com)

• WhiteHat Sentinel - WhiteHat Security (www.whitehatsec.com)

Static Source Code Analysis vendors

• Fortify - Fortify Software (www.fortifysoftware.com)

• Ounce - Ounce Labs (www.ouncelabs.com)

• Veracode – (www.veracode.com)

Find Web Application vulnerabilities - 2

Build a foundation

Find Web Application vulnerabilities - 3

Web Application Security assessment CapEx and deployment times

• 30 days to evaluate each vendor if conducting a bake-off

• 0-4 weeks to deploy chosen tool after the evaluation phase

• CapEx for web application security assessment tools will vary betweenvendors. Budget for 25K - 50K.

Static Source Code Analysis CapEx and implementation times



• CapEx for static source analysis tools will vary between vendors and willlikley depend on the chosen deployment scenario as well as how manydevelopers will be using the tool. One FTE should be expected to manage thetool, depending on the scale of environment. Budget for 50K - 100K (1K - 3Kper developer).

Build a foundation

• Mitigate immediate internet facing risk

• Block your exposure from web application vulnerabilities as close as possibleto when they are discovered. THIS IS CRITICAL!

• Buys you time to fix vulnerabilities in the underlying code.

• Web Application Firewall (WAF) will minimize threat window for eachexposure by blocking access to vulnerability until the vulnerability can befixed in the code.

Address Web Application vulnerabilities

• Address vulnerabilities in the code

• Web application security assessment tool should assist in locating specificcode level changes that need to be made

• Static Source Code analysis will point directly to specific code level changesthat need to be made

• If possible, map your web application vulnerabilities directly to your bugtracking system.

Build a foundation

Address Web Application vulnerabilities - 2

Web Application firewall (WAF) vendors

• WebDefend - Breach (www.breach.com)

• ModSecurity - Open Source (www.modsecurity.org) support offered by Breach

• SecureSphere - Imperva (www.imperva.com)

• Application Security Manager - F5 (www.f5.com)

• Citrix Application Firewall - Citrix (www.citrix.com)

• Web Application Controller - Barracuda (www.barracudanetworks.com)

Honorable mention

• Fortify Real-Time Analysis (RTA) (Formerly called Fortify Defender)(www.fortifysoftware.com)

Build a foundation

Address Web Application vulnerabilities - 3

Web Application Firewall CapEx and deployment times



• Ongoing management and fine-tuning can be expected after deployment

• CapEx for Web Application Firewalls will vary between vendors. Expectapprox. 25K-40K per appliance and you will need at least two for redundancy.

• Budget for 75K-100K

Build a foundation

• Deploy Web Application Firewall (WAF)

Detect Web Application compromise attempts

Build a foundation

Build a foundation

What is a Web Application Firewall?

• Looks at Web Application (Layer 7) data and acts upon it.

• Similar to a traditional network (Layer 4) firewall, ….

• But not really a firewall after all

• More like a gateway than a firewall, …

• But not really like a gateway either

Build a foundation

Where Web Application Firewall fits into traditional deployment architecture.

Build a foundation

Traditional network layer security is blind to application layer threats

Build a foundation

http://www.modsecurity.org/blog/archives/2008/03/web_application_4.html

Web Application Firewall Use Cases(Ivan Ristic’s Blog, ModSecurity author)

• Web intrusion detection and prevention

• ! Continuous security assessment

• ! Virtual (or just-in-time) patching

• ! HTTP traffic logging and monitoring

• ! Network building blocks

• ! Web application hardening


• You cannot protect what you cannot see.


Build a foundation




Build a foundation

http://imgs.xkcd.com/comics/exploits_of_a_mom.png




Build a foundation

• This is usually the piece that traditional operations security folks do notunderstand.

• WAF should monitor and detect application anomalies and compromiseattempts from users.

• The tricky part here is that you will likely need the help of the traditionaloperations security guys in order to successfully deploy your WAF intoproduction environment.

• WAF offers greater visibility into application security events.

• As WAF market matures, you can expect the WAF to be fed real-timevulnerabilities by your web application security assessment tool in order toproactively block newly discovered attacks.

• You will need greater visibility into application layer traffic.

• Lots of framework options available to choose from.

• Check out WASC and OWASP for more guidance here.

• Should be consistent with the web application security assessment tool youhave chosen

• Whitehat Sentinel uses Web Application Security Consortium ThreatClassification scheme (http://www.webappsec.org/projects/threat/)

• Authentication

• Authorization

• Client-side Attacks

• Command Execution

• Information Disclosure

• Logical Attacks

Decide upon threat classification framework

Build a foundation

• This is the piece overlooked by most organizations.

• You do NOT want to be blind-sided by a web application security event whileyou are earning the trust of both your management and peers.

• The operations security guys may actually want you to fail.

• Expect a lot of policy writing and approx. 4-8 weeks until total sign-off

Develop Web Application Incident Response plan

A web Application focused Incident Response plan will:

1. offer a predetermined course of action in the event of an ApplicationSecurity incident.

2. allow for an expedited reaction to an application incident or occurrence.

3. leverage all tools/personnel available in a timely, effective andpredetermined way.

4. Build confidence within your organization of your abilities.

Build a foundation

• Integrate security into SDLC

• Secured development lifecycle

• Secure design review

• Web Services / API architecture

• Document coding standards

Scope/prioritize internal Web Applicationspecific projects

• Integrate security into QA process

• Remote access to source code fromoffshore developers

• Integrate security into yourapplication design process

• Tighten up the platform framework

Ideally, you should try to build the general foundation for web applicationsecurity as referenced in the prior slides before addressing the sample internalprojects listed below.

If necessary you can do them concurrently but understand that you will need tobuild a strong web application security foundation as soon as possible in order tobe successful.

Internal projects

• Executive web application security risk awareness

• Developer Training• Java black belt (http://www.javablackbelt.com/)• Online development courses

• Recurring Presentations/events

• Security hack contests (hack-a-thon)

• Secure development training

• Strive to get everyone to start thinking like an attacker

Increase security awareness

Internal projects

Threat Modeling

• Understand all entry and exit points into the web application

• Understand threat scenarios

• Understand ‘trust boundaries’ in the application

• Understand most likely data to be targeted by attackers

• Know your ‘crown jewels’

Data Flow Diagrams

• Understand anticipated user activity within the application flow

• Understand expected data flow from one application component to the next

Threat Modeling and Data Flow Diagrams

Internal projects

• Manual line-by-line code review for all application code by a Subject MatterExpert (SME) in your application technology.

• Include all tiers in the application architecture:• client side within presentation tier• the application tier• the backend database tier

• If budget restrictions require you to prioritize between tiers, address internetfacing code first and then move on to application tier and then backenddatabase tier.

• Note: if presentation tier in your architecture can make database callsdirectly then you will need to review all code at the same time.

• CapEx should be budgeted at between 50-100K. A phased approach mayspread the cost across multiple quarters/years.

Manual code review (outside expert)

Internal projects

• Distributed Denial of Service Attacks (DDoS)• WAF should offer defense against Web Application Denial of Service

(DoS) attacks up to a point but it is not clear how much defense WAFwill offer against a focused and coordinated DDoS attack.

• May require additional services from co-lo and/or upstream ISP.

• Anti-Phishing• Companies/Services offer focused defense against targeted phishing and

other attacks at your organization’s brand name.• These brand protection services are great to have in advance but can

usually be ramped up quickly after targeted attacks are discovered.

• Security Center• Reporting features of WAF should be available for users to increase

security awareness and proactively address security weaknesses.

• Web Application Security metrics

Other possible Roadmap items to consider

Internal projects

Information security risks and threats change over time.

You must adapt to these changes.

Web application security is the current threat that you need tounderstand and be adapting to.

If you are new to web application security, it is OK because there isstill time to change and adapt.

Just remember this, …

Don’t be an information security dinosaur!

Questions ?????

Latest version of this presentation:

http://www.webappsecroadmap.com

web app sec roadmap

Technology