Teaching developers to fish OWASP AppSec

June 2004 NYC

Denis Verdon

Senior Vice President, Corporate Information Security Fidelity National Financial E-mail: [email protected] Tel: 949-221-3252 Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

http://www.owasp.org

Give a man a fish and you feed him for a day; Teach a man to fish and you feed him for a lifetime.

Chinese proverb

OWASP AppSec 2004 2

About Fidelity National Financial

OWASP AppSec 2004 3

The developer who could…..

OWASP AppSec 2004 4

If cars were built like applications….

1.

2.

3.

4.

5.

70% of all cars would be built without following the original designs and blueprints. The other 30% would not have designs.

Car design would assume that safety is a function of road design and that all drivers were considerate, sober and expert drivers.

Cars would have no airbags, mirrors, seat belts, doors, roll-bars, side-impact bars, or locks, because no-one had asked for them. But they would all have at least six cup holders.

Not all the components would be bolted together securely and many of them would not be built to tolerate even the slightest abuse. Safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact and resistance to theft.

6.

7.

Many safety features originally included might be removed before the car was completed, because they might adversely impact performance.

70% of all cars would be subject to monthly recalls to add major components left out of the initial production. The other 30% wouldn’t be recalled, because no-one would sue anyway.

8.

The after-market for safety devices would include such useful products as training wheels, screen doors, elastic seatbelts and devices that would restrict the car’s top speed to 3mph, if found to be unsafe (which would be always).

9.

Useful safety could be found, but could only be custom retro-fitted, would take six months to fit and would cost more than the car itself.

10. A DOT inspection would consist of counting the wheels and making recommendations on wheel quantity.

11. Your only warning indicator would be large quantities of smoke and flame in the cab.

12. You could only get insurance from one provider, it would be extremely expensive, require a duplicate DOT inspection, and you might still never be able to claim against the policy.

OWASP AppSec 2004 5

What has been achieved?

 Awareness is growing.

 Modern development frameworks, such as J2EE and .NET have been built with security in mind.

 Tools have been developed that begin to address application security.

 Secure coding is becoming a priority.

 Best practice libraries are now being developed.

 Training courses are springing up everywhere.

 Major Computer Science colleges are beginning to offer security-specific courses.

 OWASP.

OWASP AppSec 2004 6

Root cause analysis

 Current standards and policy are unclear.

 The language for gauging risk and applying it practically to application design has not been fully developed.

 Security frameworks have been developed (J2EE and .NET), but the language of “what, when, where and why” is missing.

 Many developers lack expertise in security specializations, such as risk analysis or cryptography.

 Many security practitioners lack expertise in OOD and in application development frameworks.

 Assumptions regarding infrastructure security can be dangerous.

OWASP AppSec 2004 7

How is FNF addressing this need?

 Tactical: Holding the fort  OWASP guide and other best practices  Testing program (Nikto, Appscan, Nessus)  Bespoke code reviews  Strategic: Defining practicable policy through:  A consistent secure application life-cycle definition.

 A common application security architecture reference model.

 A purpose-designed application security risk analysis methodology.

 Trust model.

 Security requirements analysis and definition process.

 Specific guidelines and standards.

OWASP AppSec 2004 8

Application development life-cycle

Design Build Deploy Operate Dispose

OWASP AppSec 2004 9

Application security reference model

OWASP AppSec 2004 10

Library of guidelines and best practices

 Application Security Policy Guidelines  Application Risk Analysis  Application Security Requirements Definition  Designing Secure Applications Guideline  Implementation Guidelines  .NET

  ASP J2EE  Cryptography Guidelines  Secure Application Testing Guidelines  Production Application Security Guidelines  Application Audit and Review Program

OWASP AppSec 2004 11

What I’d like to see

 Practicable standards for risk analysis and data classification.

 A common language for deriving and applying risk analysis data.

 Relevant security modeling languages.

 Common definitions of trust.

 Tools to support the methodology.

 A standards-based approach.

OWASP AppSec 2004 12

Questions?

Email: [email protected]

OWASP AppSec

June 2004 NYC Copyright © 2004 - The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License.

The OWASP Foundation

http://www.owasp.org