Establishing an Enterprise Application Security Program

1. Establishing an Enterprise Application Security Program Tony Canike, CISSP, GCIH Manager, Application Security, The Vanguard Group anthony_c_canike@vanguard.com 610-503-6525

2. What today’s talk is about • What is an Application Security program? • The need for an Application Security program in your organization • Detailed look at the components of an Application Security program • Roadmap to establish your own Application Security program This talk presumes the existence of network, server, physical, and organizational security efforts.

3. Setting the Stage • In my organization… • Application Security is an IT function • Information Security is a business function • Close cooperation and some overlap • Mix of purchased and in-house developed business applications • Many business applications developed in-house

4. What is an Application Security Program? Def. 1: An integrated approach to Application Security in your organization • Not scattershot • Not tools with shiny red buttons Def. 2: A corporate initiative to define, promote, assure, and measure the security of critical business applications. So what does that really mean…

5. People Policy Standards Awareness Training Roles Priority Expert Assistance Technology Standard Controls Input Validation Tools People, Process, and Technology all aligned to ensure secure business applications. Process • SDLC • App Inventory • Standard Requirements • Risk Management • Risk Rating • Reviews • Governance

6. Application Security: Part of the Big Picture • Conceptual Information Security Dashboard Business Applications Data Security Vendors & Partners Business Processes Computing Infrastructure Intrusion Detection Network & Telecom Infra Physical Security Compliance Business Continuity Incident Response Fraud Prevention Simplified example only. A complete dashboard could have 20-30 indicators.

7. Benefits of an Application Security program • Knowledge to… • keep the C-suite informed • communicate areas of opportunity • develop high-level action plans • assist the application development teams • optimally allocate resources and funds • protect client and corporate assets

8. Why do you need an Application Security program? • What are your big application security issues, anyway? • Can you back up recommendations with data? • Can you justify expenditures? • Security is more then securing the network perimeter… • …do you have data to support that? • Your network security colleagues have numbers, you need numbers too. • Use Data, Metrics, Numbers, Facts • Data-driven decision making • Really know what is working and what is not • Motivate actions • Suggestions for metrics collection throughout presentation

9. Knowledge in multiple dimensions Leading Indicator • Training and Awareness • Are IT Staff trained and aware of security issues? • SDLC Maturity and Compliance • Is security baked-in to your Software Development Life Cycle? • Are you following your SDLC? • Reference Architectures and Standard Controls Provided? • Security Assessment Coverage of the Application Space • Are you doing enough assessments? Frequently enough? • Anything you don’t know you don’t know? • Application Risks and Vulnerabilities • When are security problems found? During Code? Test? Prod? • Are you mitigating risks in a timely fashion? Leading Indicator Post Indicator

10. How much security do we need?

11. People Policy Standards Awareness Training Roles Priority Expert Assistance Technology Standard Controls Input Validation Tools Components of an Application Security program Process • SDLC • App Inventory • Standard Requirements • Risk Management • Risk Rating • Reviews • Governance

12. People: Policies and Standards • Information Security Policies • IT Architecture Standards • Reference application architectures (w/security) • Standard security controls identified • SDLC Defined • Standard Application Security Requirements • Use reviews to govern and enforce • Dashboard Indicators, Metrics

13. People: Awareness and Training • Awareness of policies and standards • Information Security • Corporate intranet or newsletter articles • Web-based training • Training • Security architects • Managers • Technical leads • Developers • Testers • Etc… • Dashboard Indicators, Metrics

14. People: Define Specialized Roles • Security Architects • Understand standard application controls and how to implement them • Directly supporting application development • Setting enterprise-wide standard security architecture • Application Security Assessment Team • Small, quasi-independent team • Assess architectures and test for vulnerabilities • Access Management Team • Business group grants access to business applications • Keeper of the keys (literally and figuratively) • Not developers, not users, not system admins

15. People: Prioritize Security • Time to market, business functionality, and cost all compete with security concerns. • Executive attention • One suggestion: IT VP’s present their security metrics/dashboard to an executive committee quarterly • Report security vulnerabilities as defects • Defect-elimination mentality already engrained? • If so, leverage it. • If not,…

16. People: Expert Assistance • Security experts are available to application development teams • Security Architects • Central team to maintain standard security controls • Eval, purchase, development, support of technical controls • Access management team • Information Security • Product Vendor resources • Consultants as necessary

17. People Policy Standards Awareness Training Roles Priority Expert Assistance Technology Standard Controls Input Validation Tools Components of an Application Security Program Process • SDLC • App Inventory • Standard Requirements • Risk Management • Risk Rating • Reviews • Governance

18. Process: Software Development Life Cycle • Integrate security steps into your SDLC • Will take a few iterations to mature. • Baked-in, not bolted-on • End-game penetration test is not sufficient • Find security issues early • Much easier, cheaper to fix • Measure compliance • Self-reporting • Audit a sampling • Voice of Practitioners • Are the processes working? • Dashboard Indicators, Metrics

19. Process: Application Development Life Cycle Application Categorization Security Requirements Access Control Input Validation Security Architecture Review Design & Code Review Unit & Integration Test System Test Categorize Vulnerability Test Governance Review Define Requirements Build Controls Verify Controls Governance Review Pre-Elev Risk Review Risk Management Track Security Metrics Track and Manage Defects and Risks

20. Process: Inventory and Categorize your Applications • List all your business applications, the business owner, and the IT owner (might be hard) • Categorize applications w.r.t. criticality of security • Potential Business Impact • Quick Technical Assessment – surface area, complexity, data classification • Ref. NIST 800-64 and FIPS 199 • Use categorization to prioritize security attention and assessments. • Assessments Performed? How recently? • Dashboard Indicators, Metrics

21. Process: Standard Security Requirements • Define Security Requirements Standards for your business applications. • Which controls are necessary • When are they necessary (applicability) • Why are they necessary (e.g. SEC, SOX, etc.) • Easy to use reference for requirements teams • Standard method to implement each control • Provide reference on how to implement • Requirements for requirements • E.g. The need to specify functional business requirements for access control

22. Process: Security Assessments of Applications • Choose types of assessments that fit your organization. • Security Architecture/Design Reviews • Security Code Reviews • Application Vulnerability Tests • Risk Acceptance Review • External Penetration Test of Production Applications • White Box Philosophy – look inside the application • Use all the advantages you have • Past reviews, design documents, code, logs, interviews, etc. • Attackers have advantages you don’t, don’t tie your hands. • Part of your SDLC • Define which reviews when, by whom, and how in your SDLC • Don’t underestimate the amount of work necessary for communication, scheduling, report writing, logistics

23. Security Architecture/Design Review • Architecture/Design time assessment of an application and its security controls • Component interface and connection driven • Enumerate through the interfaces and connections considering threats, vulnerabilities, and risks • STRIDE • Identify non-standard, home-brewed or missing security controls • Issue a report • Identify vulnerabilities to mitigate or fix • Identify issues for follow-up

24. Security Code Review • Focus on code relevant to security • Utilize experts • Consider consulting firms with specialized techniques. • Specialized Tools • Have a technique to wade through 5 million lines of code • Define Scope and Purpose • Project Manager: “since you are reviewing my code, I can skip all my code reviews, ok?” Not so fast… • You are not reviewing the code for the application team – they are still on the hook for code quality.

25. Application Vulnerability Test • Hands-on testing of application around System Test time • “Port 80” types of attacks • Goal is to find most of the problems early and get them fixed. • Not trying to prove a point, not playing capture-the-flag • Use a small dedicated team supported by consultants • Educate and collaborate with development teams • Use all advantages you have – white box • Logs, source code, business knowledge, prior assessments • Define purpose – are you going to validate that the application meets all of its security requirements? • Probably not. Make that clear up-front. • Define scope – which components are being tested? • Use the architecture diagram

26. Process: Information Security Risk Management • Document your risk rating process • Common risk rating method and scale • Consider business impact and likelihood/DREAD factors • Rationale for a particular risk rating known and documented • Common taxonomy • Categorize and count – perhaps 10 categories • Weed out false positives early – reduce noise • Draft, Review, Revise • Apply to all IT-owned InfoSec Risks from all sources • Consultants, IT Security Assessments, InfoSec Assessments, Internal Audit (if possible), Corporate Risk Management, etc. • Develop/Adapt process through consensus • Calibrate!

27. Example Job Aid – Likelihood Factors Well Known? Mitigating Controls Attractive? WHO? Skill Level HIGH Public Direct Access All Internet Unintentional CORP Inc Very Attractive CORP Inc Internal Customers One Control No special skills LIKEL IHOOD IT Employees Somewhat Attractive Proprietary Technical Two Controls LOW Very Technical System Admins Not Attractive Three or more Theoretical Illustrative example only.

28. Process: Information Security Risk Management (cont.) • Common Repository for tracking • Assessments • Risks/Vulnerabilities • Mitigation Actions and Status • Common report formats • Differing formats from different assessment teams (internal, consultants, audit) confuses everyone • Common summary reports • Open risk counts, severity, category, owners, time-to-close, … • Train management on how to read summary reports • Dashboard Indicators, Metrics

29. Process: Risk Review and Acceptance • Review known security risks and mitigation status prior to production elevation. • Business owners key participants • Need to understand and accept (or not) outstanding risks prior to elevation • No surprises… • Dashboard Indicators, Metrics

30. Process: Other tests and assessments…. • Of course, utilize the gamut of security assessments, including • Internet Penetration Tests • Network and vulnerability scans • Server security scans • Up to you to define the boundary of “Application Security” for your organization. • Cooperate, avoid fiefdoms

31. Process: Governance Team Reviews • IT-wide governance team of practitioners reviews summaries of security assessments and tests • Were the risks rated properly? • Was the assessment or test complete? • Is the responsible individual taking responsibility and fixing the issues? • What are the common themes and trends? • What improvements to people-process-technology can be implemented?

32. People Policy Standards Awareness Training Roles Priority Expert Assistance Technology Standard Controls Input Validation Tools Components of an Application Security Program Process • SDLC • App Inventory • Standard Requirements • Risk Management • Risk Rating • Reviews • Governance

33. Technology: Standard Controls • Provide standard technical controls to your application development teams. • Determine needs and prioritize • Consider authentication, access control, certificate management, cryptography, accountability, logging, detection, ... • Reuse opportunity • Don’t let app teams “roll their own” or reinvent the wheel. • Central shared security controls team? • Handle eval, purchase, integrate, build, test, support • Support application teams • Provide reference architectures with integrated security controls • Dashboard Indicators, Metrics

34. Technology: Standard Controls (cont.) • Do your standard security controls cover all your application architectures? • LAN/Desktop login • Web (Internet, intranet, J2EE, .NET, LAMP, etc.) • Thick desktop clients • Application Service Providers/Partners – SSO • UI tier, Business logic tier, data tier • Web Services

35. Technology: Input Validation • Is each application developer building their own input validation code? • Or do you have a standard mechanism? • Is there a standard signature/architecture/API and a reuse library that developers can contribute to? • For all your application models? • Do requirements/use cases/UI specifications document necessary allowed values for each input field?

36. Technology: Security Tools • Tools • Developers • System Testers • Security Assessors/Testers

37. People Policy Standards Awareness Training Roles Priority Expert Assistance Technology Standard Controls Input Validation Tools People, Process, and Technology all aligned to ensure secure applications. Process • SDLC • App Inventory • Standard Requirements • Risk Management • Risk Rating • Reviews • Governance

38. That’s a long list… • Implementing all these components of an Application Security program is a tall order • Adapt to your needs • In-house development • Purchased applications • Outsourced applications • In-house SDLC vs. outsourcing requirements and contract language

39. Roadmap to your own Application Security Program • Assess Current State – what are your organizational and process deficiencies? • Info Sec and Internal Audit will help you here! • Develop and sell your vision • It’s a integrated program • Identify and educate your stakeholders • Have a roadmap and a project plan – 2-4 year effort

40. Where to start? • Awareness and Training • 2-hour course: $100-200/seat • Seeing the look on the IT VPs’ faces when they get SQL Injection: Priceless • Policies and Standards • Application Assessments and Reviews • Get some data • Strive to be consistent and uniform • Support Development Teams

41. Questions?

42. More Information • ISF Standard of Good Practice • ISF has a strong Business Impact assessment process (membership required) • NIST Security Considerations in the Information System Development Life Cycle (800-64) • OWASP Guide • Howard and LeBlanc Writing Secure Code