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

CIOCIO

Library and Academic IT

Support

Library and Academic IT

Support

IT Support Operations

IT Support Operations

IT Developmentand Engineering

IT Developmentand Engineering

Application Development (11)

Application Development (11)

Systems Development (4)

Systems Development (4)

Project Management (3)

Project Management (3)

Verification and Testing

(1 + students)

Verification and Testing

(1 + students)

Image Development (1)

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

• 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