Embedding Security into a Software Development Methodology April 5 th , 8:30 AM Jonathan Minter

1. Embedding Security into a Software Development Methodology April 5th, 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

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 • http://www.liberty.edu/sdm • 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 MinterDirector, IT Development and EngineeringLiberty Universityjonathan@liberty.edu434-592-7301