Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Like this? Share it with your network


Application Portfolio Risk Ranking: Banishing FUD With Structure and Numbers



Far too often application security decisions are made in an ad hoc manner and based on little or no data. This leads to an inefficient allocation of scarce resources. To move beyond fear, uncertainty ...

Far too often application security decisions are made in an ad hoc manner and based on little or no data. This leads to an inefficient allocation of scarce resources. To move beyond fear, uncertainty and doubt, organizations must adopt an approach to application risk management based on a structured process and quantitative data. This presentation outlines such an approach for organizations to enumerate all the applications in their portfolio. It then goes through background information to collect for each application to support further decision-making. In addition, the presentation lays out an application risk-ranking framework allowing security analysts to quantitatively categorize their application assets and then plan for assessment activities based on available budgets. This provides the knowledge and tools required for them to use the approach on the applications they are responsible for in their organization. Please email dan _at_ denimgroup dot com for a template spreadsheet and a how-to guide.



Total Views
Views on SlideShare
Embed Views



7 Embeds 156

http://blog.denimgroup.com 125
http://denimgroup.typepad.com 11
http://denimgroup.posterous.com 8
http://www.denimgroup.com 6
http://web.archive.org 4
http://translate.googleusercontent.com 1
http://denimgroup.com 1



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Application Portfolio Risk Ranking: Banishing FUD With Structure and Numbers Presentation Transcript

  • 1. Application Portfolio Risk Ranking Banishing FUD With Structure and Numbers Dan Cornell OWASP AppSec DC 2010 November 11th, 2010
  • 2. Overview • The Problem • Information Gathering • Application Scoring • Risk Rank & Tradeoff Analysis • Discussion • Conclusion, Next Steps, and Q&A 1
  • 3. Some Key Questions for Today’s Session • Where do you start? • What applications represent the biggest risk? • What attributes make applications more or less risky? • What are the most cost-effective way to manage the risk of inherited applications? • What approaches might work for your organization? 2
  • 4. Desired Outcomes • Understand risk-based options for managing the security of inherited applications • Develop a framework for ranking risks with specific applications • Understand some of the decision-making factors that come into play when risk-ranking applications • Apply one tactic from what you learn today next week at your organization 3
  • 5. Personal Background • Denim Group CTO • Developer by background • Java, .NET, etc 4
  • 6. Denim Group Background – Professional services firm that builds & secures enterprise applications – Secure development services: • Secure .NET and Java application development • Post-assessment remediation • Secure web services – Application security services include: • External application assessments • Code reviews • Software development lifecycle development (SDLC) consulting • Classroom and e-Learning instruction for developers 5
  • 7. What you Don’t know CAN Hurt You • Passion: Get security professionals to ask a better set of questions • Today’s presentation focuses on helping you increase your IQ in the arena of software portfolio risk 6
  • 8. Background – the Current State of Affairs • Creating meaningful enterprise-wide software security initiatives is hard • The vast majority of info regarding software security focuses on testing software writing more secure code or SDLC process improvement • Most organizations have hundreds or thousands of legacy applications that work! – They represent money already spent – ROI? – They are viewed “part of the plumbing” by management – The codebases can be millions of lines of code • Industry is focused on web applications – Other software risks must be taken into consideration • Web services, mobile applications, SaaS, certain desktop applications 7
  • 9. Key Facts • 66% have adopted a risk-based approach to remediation of application vulnerabilities • 71% have an executive or team with primary ownership and accountability for application security • 66% have defined communications channels between security, operations, and development teams – Source: “Securing Your Applications: Three Ways to Play,” Aberdeen Group, August 2010 8
  • 10. Goal for Our Model • Transparent – Decisions and calculations should be explainable • Adaptable – Not every organization has the same drivers, goals or resources • Practical – Get something that works and iterate 9
  • 11. Methodology • Steal steal steal! – Andrew Jacquith’s Application Insecurity Index (AII) from his book Security Metrics – Nick Coblentz’s blog posts on the topic – Other example spreadsheets, etc • Simplify simplify simplify! – Great is the enemy of the good enough – Any information collected should provide value – Work in progress • Test with organizations • Repeat 10
  • 12. Step 1: Develop Initial Criteria • Business Importance Risk • Assessment Risk 11
  • 13. Step 2 – Information Gathering • Build a Portfolio of Applications – Public-facing web sites – Customer-facing web applications – Partner-facing web applications – Internal- or partner-facing web services – Customer Relationship Management (CRM) systems – Financial applications – “Green screen” mainframe applications – Software as a Service (SaaS) applications 12
  • 14. Step 2 – Information Gathering (Continued) • Collect Background Information – Development Details – Vendor (if any) – Audience – Hosting Details • Assess the Data – Type (CCs, PII, ePHI, etc) – Compliance Requirements • Determine the Scale – Lines of Code – Dynamic Pages – Concurrent Users – User Roles 13
  • 15. Step 2 – Information Gathering (Continued) • Assess the Underlying Technology – Infrastructure (OS, hardware, etc) – Platform (.NET, Java, PHP, etc) – Versions • Assess the Security State – Assessment Activity (type, date, etc) – Vulnerabilities (high, medium, low) – Protection (IDS/IPS, WAF) 14
  • 16. Step 3 – Application Scoring • Business Importance Risk – Business Function (customer interface, internal but public-facing, departmental use only) – Access Scope (external, internal) – Data Sensitivity (customer data, company confidential, public) – Availability Impact (serious, minor, minimal, or no reputation damage) 15
  • 17. Step 3 – Application Scoring (Continued) • Technology Risk – Authentication (methods, enforcement) – Data Classification (formal approach or not) – Input / Output Validation (structured or not) – Authorization Controls (resource checks in place or not) – Security Requirements (explicitly documented or not) – Sensitive Data Handling (controls in place like encryption or not) – User Identity Management (procedures in place for account creation, access provisioning, and change control or not) – Infrastructure Architecture (network segmentation, patching) 16
  • 18. Step 3 – Application Scoring (Continued) • Assessment Risk – Technical Assessment (assessment activity, vulnerabilities still present) – Regulatory Exposure (unknown, subject to regulation) – Third-Party Risks (outsourced development, SaaS hosting, etc) 17
  • 19. Step 4: Determine Assessment Approach • Currently using OWASP Application Security Verification Standard (ASVS) • Determine what you consider to be a Critical, High, Medium, Low • Determine what assessment approach/standard you want to use 18
  • 20. Results Comparison • Let’s analyze our results • Apply quantitative decision-making analysis concepts – Want to understand what level of effort addresses the highest amount of risk • Tradeoff analysis 19
  • 21. Evaluation • Pros – Provides for a structured approach – Calculations are observable – Standards can be set for specific organizations • Cons – Can seem like a lot of data to collect – Technology Risk is hard to get at a proper level of granularity – Excel spreadsheet combines data and code – Needs work for dealing with “cloud” stuff 20
  • 22. So where do you go from here? 21
  • 23. Example Artifacts • Application Tracking and Risk-Ranking Spreadsheet – What are the applications? – What are their characteristics? – How do they rank against one another? • Risk-Ranking Planning Spreadsheet – Which applications are critical, high, medium or low? – How are you going to deal with each application? 22
  • 24. Potential Follow-up Options • End of Life • Remediate • Potential Testing Approaches – Tailoring to Documented Risk – Work identified list from top to bottom • Application Security Verification Standard (ASVS) – Levels of application-level security verification that increase in breadth and depth as one moves up the levels – Verification requirements that prescribe a unique white-list approach for security controls – Reporting requirements that ensure reports are sufficiently detailed to make verification repeatable, and to determine if the verification was accurate and complete. 23
  • 25. What you can do now! • Collect or scrub your initial application inventory • Develop relationships with 3rd parties who can help you through the identification process • Find a peer that is conducting the same risk ranking • Familiarize yourself with OWASP OpenSAMM and OWASP ASVS 24
  • 26. Conclusion • Managing the security of inherited applications can present the most severe headaches for someone building a software security program • A risk-based approach is really the only economically feasible approach given the size/complexity of the problem • Understanding certain attributes of inherited applications is critical to applying a risk-based management approach 25
  • 27. Resources • “Web Application Security Portfolios, ISSA Journal, May 2009, Coblentz, Nick. • Open Web Application Security Project Open Software Assurance Maturity Model, www.owasp.org • Open Web Application Security Project Application Security Verification Standard, www.owasp.org • “How-to-Guide for Software Security Vulnerability Remediation,” Dan Cornell, Denim Group, October 2010 • Cloud Security Alliance • “Securing your Applications,” Aberdeen Group, Brink, Derek, August 2010 26
  • 28. Contact Dan Cornell dan@denimgroup.com (210) 572-4400 www.denimgroup.com blog.denimgroup.com Twitter: @danielcornell Email me for a copy of the example Excel spreadsheet 27