Bootstrapping the Application Assurance Process

1. Bootstrapping the Application Assurance Process Sebastien Deleersnyder Belgium OWASP Chapter Leader Ascure sdl@ascure.com

2. Sebastien Deleersnyder? • 5 years of Developer Experience • 5 years of Information Security Experience • Principal Application Security Consultant @ Ascure: • Web Application/Services Security Testing • Training Web Application/Services Security • Initiating & Improving Application Security Assurance • Belgian OWASP Chapter Leader

3. Agenda • Application Security Assurance? • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

4. Agenda • Application Security Assurance? • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

5. Application Security Problem • Business demands more: • automation • availability • adaptability • Growing connectivity / user base • Increasing complexity of software • Rush software out without adequate security testing • Poor security training and awareness 75% of vulnerabilities are application related (Gartner + NIST-ICAT)

6. Cost of Insecure Software • More maintenance (updates, patches) • Lost: • Money • Productivity • Information • Image, reputation

7. Unauthorized access The Solution Application Security Assurance Understand and manage your software security risk Network Software Data STOP

8. Application Security Assurance Combination of People, Processes, and Technology to identify, measure, and manage Risk presented by COTS(*), open source, and custom applications. (*) Commercial Of The Shelf

9. Agenda • Application Security Assurance • People • Processes • Technology • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

10. People • Awareness decision makers • Board of Directors • Audit and Assurance (Risk Management) • CEO/CFO/CIO • Executive(s) responsible for systems development and change management • Sales & Product Management!

11. People • Teach your developers to “fish”: 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 • Meaning: • Developer awareness • Secure design guidelines • Secure implementation practices

12. Agenda • Application Security Assurance • People • Processes • Technology • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

13. Processes • Build security into • Development process • Deployment process

14. “Integrate” Security within Application Life Cycle Risk Based Security Testing Secure Config / CM / App FWs Security Requirements / Abuse Cases Threat Modeling / Secure Design Code Review Requirements Use Cases Design Code Test Deploy

15. Security Requirements / Abuse Cases • Define “Secure” & “Reliable” • Use <-> Abuse Cases • UML based • Better understanding • Foundation rest AppSec controls

16. Abuse Cases Source: Templates for Misuse Case Description, Sindre & Opdahl

17. Threat Modeling • Select mitigation Strategy & Techniques based on identified, documented and rated threats. • Benefits: • Prevent security design flaws • Identify & address greatest risks • Increased risk awareness and understanding • Mechanism for reaching consensus • Cost justification and support for needed controls • Means for communicating results

18. Secure Design • Principles (*) • Secure the weakest link • Practice defence in depth • Fail securely • Follow the principle of least privilege • Compartmentalize • Keep it simple • Promote privacy • Remember that hiding secrets is hard • Be reluctant to trust • Use your community resources • Future proof security design! (*) Building Secure Software, Viega-McGraw

19. Code Review • Security bugs subset of implementation bugs! • Static / dynamic analysis tools • Requires manual inspection • Threat-based • Benefits: • Improves code quality • Prevents security bugs • Increased developer awareness and understanding

20. Application Security Testing • Focus on application vulnerabilities • Tools can do the automated work • Experienced Testers • Black / White Box security testing

21. Deployment Process • Ensure the application configuration is secure • Security is increasingly “data-driven” • XML files, property files, scripts, databases, directories • How do you control and audit this data? • Design configuration data for audit • Put all configuration data in CM • Audit configuration data regularly • Don’t allow configuration changes in the field • Gap Development - Deployment

22. Agenda • Application Security Assurance • People • Processes • Technology • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

23. Technology • Do not develop on islands, but look for company wide: • Frameworks J2EE, .NET • Web Services: new ballgame or same thing? • Leverage PKI, IAM initiatives • Vulnerability Scanners • Application level firewalls

24. Agenda • Application Security Assurance • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

25. Risk Management • Risk Management • “Looking both ways before crossing the road” • Risk • “The possibility of suffering harm or loss” • Management • “The act or art of managing; the manner of treating, directing, carrying on, or using, for a purpose”

26. Risk Management? The process concerned with identification, measurement, control and minimization of security risks in information systems to a level commensurate with the value of the assets protected.

27. Risk Management • Deeply influenced by business objectives • Each business has different risk profile • Risk changes over time

28. The foundation of security • Risk is the combination of a threat exploiting some vulnerability that could cause harm to some asset.

29. Handling Risks • Methods of risk treatment: • Mitigate or suppress • Accept • Transfer (insurance) • Ignore (poor – often used) • Types of countermeasures • Preventive • Detective • Corrective • In case of risk acceptance • Request documented justification • Get formal approbation (sign-off) by senior management • Have the decision reviewed after 6 to 12 months

30. Residual Risk • Residual Risk is a combined function of • (1) a threat less the effect of some threat reducing safeguards; • (2) a vulnerability less the effect of some vulnerability reducing safeguards and • (3) an asset less the effect of some asset value reducing safeguards.

31. Risk Analysis – Thread Modeling • Company Level - Risk Analysis: • Perform Business Risk Analysis • Identify Critical Business Applications • Focus on Business Risks • Ownership? • Application Level -Threat Modeling: • What are the real threats against the application? • Focus on Technical Threats

32. Success Factors • Obtain management support • Involve Business and Technical experts • Designate focal points • Define procedures • Document and maintain result

33. Results • Assurance that greatest risks have been identified and addressed • Increased awareness and understanding of the risks • Mechanism for reaching consensus • Cost justification and support for needed controls • Means for communicating results • Compliancy & Audit reporting

34. Cost vs. Security Sub-optimal Security Spending Cost Targeted balance Maximum allowable cost Maximum viable security Security “Maximum allowable cost” is found through Risk Management.

35. Agenda • Application Security Assurance • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

36. How to Start? • No Big Bang approach • Trigger can be (bad) result of Web App Pen Test • First business case! • Then Bootstrap!

37. Business Case • For use throughout the lifecycle and the entire software portfolio: • Contracting Phase • Development Phase • Deployment/Production Phase • Audit Phase • Benefits: • Cost savings • Risk measurement and reduction • Compliance reporting

38. Cost Savings • Significantly reduce the costs associated with new and deployed products : • A flaw that costs $1 to fix in the design and development phase will cost $100 to correct once it is deployed • Reduce development time and number of cycles • Patch management costs • Contractor and vendor costs “Removing only 50 percent of software vulnerabilities before use will reduce patch management and incident response costs by 75 percent.”(John Pescatore, Gartner)

39. Risk measurement and reduction • Eliminate vulnerabilities before they become liabilities • Manage the risks of serious financial loss, negative publicity, legal liability, loss of contracts, erosion of market share, degraded performance or other serious business impact as a result of a failure in security • Set, enforce and report that software assurance thresholds are maintained • Measurable reports prove progress internally and for compliance

40. Compliance Reporting • Compliance reporting: • Comply with legal and regulatory requirements • Regularly assess risk, disclose vulnerabilities and weaknesses, and prove progress both internally and for compliance requirements • Scope & application • Risk assessments are mandatory for most regulations, including application vulnerability detection • Example internal control frameworks: CobiT, ISO 17799 • Example regulations: Basel II, FISMA (NIST 800-53), DoD 8500.2, Sarbanes-Oxley, FDA, HIPAA …

41. BootStrap! • Identify current way of working! • Set goals and start with phased approach • Compare this with security strategy (can already be set out in a secure development policy) • Perform a gap analysis and proceed with process improvement cycles: • Tailor to Company Culture! • Driven by Risk Management!

42. Quality – Application Security Analogy

43. Driver for Improvement Process Risk Management • Accountability • Organisation • Reporting (develop metrics) Strategy Governance • Development • Deployment

44. Company Wide • Identify Business Critical High Risk projects to focus on. • E.g. through BIA • Focus on business risks! • Must align Application Security Assurance with the company's "Risk Appetite"

45. Process Gateway Checks • Introduce process gateway checks to be formally reported by project manager for project board sign-off (including residual risk!) • Introduce Application Security Controls in phased approach • Requirements phase is key for new projects: • Security specifics must be part of functional requirements (not bolted on later!) • Awareness for stake-holders / project sponsors!

46. “Natural” Allies • QA: • Security vulnerabilities are to be considered bugs, the same way as a functional bug, and tracked in the same manner. • PMO: • Factor some time into the project plan for security. • Consider security as added value in an application. – $1 spent up front saves $10 during development and $100 after release

47. Application Security Defect Tracking and Metrics • “Every security flaw is a process problem” • Tracking security defects • Find the source of the problem • Bad or missed requirement, design flaw, poor implementation, etc… • ISSUE: can you track security defects the same way as other defects? • Metrics • What lifecycle stage are most flaws originating in? • What security mechanisms are we having trouble implementing? • What security vulnerabilities are we having trouble avoiding?

48. Roles • Role of security architect (cross-development projects): • ensure security goals are reached during all cycles of the development process • create awareness within development teams, business • bridge function to "IT Security" • mentor the security engineers and project leaders • Role of security engineer (part of project team) • SPOC within development team for all security related matters. • Search for Champions!

49. Agenda • Application Security Assurance • Risk Management • Bootstrap Application Security Assurance Cycle • User Story: Mercator Insurances • Outsourced Development • Roundup

50. Bootstrapping User Story – Mercator Insurances • Triggered by application assessment on critical Web Applications • Tailored Best Practices to Mercator Development & Deployment Process • Interviews with key actors • Support by Mercator Security Architect • Included PMO • Workshops for developer awareness & involvement in AppSec Assurance process