1. 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 OWASP AppSec June 2004 NYC http://www.owasp.org Teaching developers to fish Denis Verdon Senior Vice President, Corporate Information Security Fidelity National Financial E-mail: denis.verdon@fnf.com Tel: 949-221-3252

2. OWASP AppSec 2004 2 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

3. OWASP AppSec 2004 3 About Fidelity National Financial

4. OWASP AppSec 2004 4 The developer who could…..

5. OWASP AppSec 2004 5 If cars were built like applications…. 1.70% of all cars would be built without following the original designs and blueprints. The other 30% would not have designs. 2.Car design would assume that safety is a function of road design and that all drivers were considerate, sober and expert drivers. 3.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. 4.Not all the components would be bolted together securely and many of them would not be built to tolerate even the slightest abuse. 5.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.Many safety features originally included might be removed before the car was completed, because they might adversely impact performance. 7.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.

6. OWASP AppSec 2004 6 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.

7. OWASP AppSec 2004 7 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.

8. OWASP AppSec 2004 8 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.

9. OWASP AppSec 2004 9 Application development life-cycle Design Build Deploy Operate Dispose

10. OWASP AppSec 2004 10 Application security reference model

11. OWASP AppSec 2004 11 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

12. OWASP AppSec 2004 12 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.

13. 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 OWASP AppSec June 2004 NYC http://www.owasp.org Questions? Email: denis.verdon@fnf.com