Embedding Security into a Software Development Methodology April 5 th, 8:30 AM Jonathan Minter Director, IT Development and Engineering Liberty University

2 Overview About the environment Establishing a software development methodology Changes made to the methodology relative to security Challenges, successes, and future direction

3 About the Environment Growing Christian liberal arts university in Lynchburg, VA 8,000 residential students 12,000 distance students Growing 20% per year for last several years Emphasis on growth continues Beginning phases of SCT Banner implementation

4 Liberty University IT CIO Library and Academic IT Support IT Support Operations IT Development and Engineering Application Development (11) Systems Development (4) Project Management (3) Verification and Testing (1 + students) Image Development (1)

5 Drivers for a Methodology Growing staff Impending ERP project with department- wide retooling Increasing complexity of projects Desire to align with industry best practices Desire for a training plan for developers

6 Establishing a Methodology Began in April 2004 Created task force of myself and three others –Developers –Project manager Methodology created by peers, not handed down by management Created in an iterative, incremental way

7 Goals of the Methodology Define areas of expertise and knowledge Enable communication among IT Development employees, customers, and other IS employees Flexible for all projects, large and small Flexible for each project to tailor the methodology Support iterative and incremental development

8 Overview of Phases

9 Structure of the Methodology Each phase is defined with the following components –Tasks –Artifacts –Questions to answer –Milestone for completion Project managers are responsible for enforcing the methodology

10 Current Status of the Methodology Finishing Stabilizing phase Slowly working through adoption –Department meetings –Empowerment of project managers –Personal conversations –Lessons learned –Management direction

11 Security and the Methodology Security must be considered throughout the lifecycle It is difficult to patch security onto a product after development Developers create vulnerabilities, just like they create bugs Business units must understand the nature of security as it applies to their systems All security problems are ultimately software problems

12 Interaction with the SEI Conversation started with Carol Woody at last year’s Security Professionals Conference Continued onsite in August 2004 After Carol’s visit and subsequent discussions, several changes were made to the methodology…

13 Methodology Changes - Envisioning Security Analysis –High-level view of application in the context of security –How sensitive is this product? –Integration into risk assessment –Use of security levels (Homeland Security style)

14 Methodology Changes - Planning Security Checklist –Focused on identifying specific security risks –Use of standard “Top 10” lists OWASP Top 10 SANS Top 10 –A guide to keep the developer focused on security during coding Integration into Requirements –Misuse cases –Engagement of product stakeholders

15 Methodology Changes - Developing Security Implementation –Use of security checklist developed in previous phase Peer Reviews –Validation that the checklist was followed Test Planning –Should include tests for security vulnerabilities –Setup for testing team

16 Methodology Changes - Stabilizing Security Testing –Testing against security checklist and requirements –Currently evaluating use of automated tools for vulnerability assessment Deployment Planning –Well documented deployment plan reduces hacking at go-live

17 Successes Security conversation has started –Developers –Business community at large Setup of Verification and Testing Unit –Oversee testing of all applications –Oversee deployments –Developer training on validation and security –“Defective software is insecure software” Slowly getting training and awareness –Circulation of articles and resources –Verification and Testing Unit a key part

18 Challenges Adoption of the methodology as a whole –Large scale change in behavior and culture –Can’t be mandated, must be internalized Same applies to security –Yesterday we didn’t care about security –Now we do… Difficulty in applying abstract security concepts to actual code Rapid pace of software development –Business users want features and assume security

19 Future Direction Refinement of methodology through use Adoption of security mindset throughout the University Better ground-level training of developers Use of automated tools to assist in testing Broadening methodology to better accommodate systems implementations vs. development efforts

20 Conclusion Questions/comments Contact Information: Jonathan Minter Director, IT Development and Engineering Liberty University