1.Agile and Secure Can We Be Both?San Antonio AITPAugust 15th, 2007

2. Agenda Background Evolution of traditional software development methodologies Benefits of Agile development Requirement for Secure development Agile and Secure Questions 1 3. Background Programmer b b k Pby backgroundd Both .NET and JEE: MCSD, Java 2 Certified Programmer Developer focused on security, not a security professional looking atdevelopment Denim Group Software Development: .NET and JEE NET Software / Application Security Vulnerability Assessments, Penetration Tests, Training, Mentoring Basis for this presentation: Work with our customers doing SDLC security mentoring Challenges facing our own agile development teams gggp Deliver projects in an economically-responsible manner Uphold security goals2 4. Evolution of Traditional Software Development Methodologiesp g Ad Hoc Waterfall 3 5. Ad Hoc Software Development Early days of computing Focus was on hardware Software was secondary No structure cowboy coding Became unacceptable as software systems became larger and more critical 4 6. Waterfall Software Development Treat software engineering as any structure engineering process House building metaphor 5 7. Waterfall Software Development Integration Requirements Architecture Design Coding Deployment Testing6 8. Problems with Waterfall Model Creating software is different than creating bridges or buildings Creativity required throughout the process not just at the outset Very documentation heavy Changes are expensive Must go back up the waterfall for impact analysis Business requirements change over time By the time you finish a system, the target has moved7 9. Enter Agile MethodsBe more responsive to business concernsIncrease the frequency of stable releasesDecrease the time it takes to deploy new featuresDo not waste time on superfluous documentation andpplanning g 8 10. Notable Agile Methods eXtreme Programming (XP) Feature Driven Development (FDD) SCRUM MSF for Agile Software Development Agile Unified Process (AUP) Crystal9 11. Manifesto for Agile SoftwarepDevelopmentIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planSource: http://www.agilemanifesto.org/10 12. Agiles Core Values Communication C i tiSimplicityFeedbackCourage 11 13. Principles of Agile Development Rapid Feedback The system is appropriate for the intended audienceaudience. Simple Design The code passes all the tests.Incremental Change Th code communicates everythingThe dihi it needs to. Embracing Change The code has the smallest number of classes and methods. Quality Work 12 14. Agile Practices Customer: scope, prioritiesand release dates The Planning Game Developer: estimates estimates,consequences and detailed The Driving Metaphor schedulingShared VisionOn-Site Customer Development iterations or Small Releasescycles that last 1-4 weeks. Release iterations as soonas possible (weekly, monthly,quarterly). 13 15. More Agile Practices Collective OwnershipTest DrivenContinuous IntegrationCoding Standards gPair Programming 14 16. The Agile Practitioners Dilemma Practitioner s Agile Forces:Secure Forces: Be more responsive toComply with more business concernsaggressive regulatory Increase the frequency environment of stable releases Focus on need for Decrease the time it security takes to deploy newTraditional approaches features to security require Do not waste time on additional superfluousdocumentation and documentation andplanning (DOh!) planning 15 17. Definition of Secure A secure product is one that protects the confidentiality, p py,integrity, and availability of the customers information, and theintegrity and availability of processing resources under control ofthe s stems o ner or administratorsystems owner administrator. -- Source: Writing Secure Code (Microsoft com)(Microsoft.com)16 18. A Secure Development Process Strives To Be A Repeatable Process Requires Team Member Education Tracks Metrics and Maintains AccountabilitySources: Writing Secure Code 2nd Ed., Howard & LeBlancThe Trustworthy Computing Security Development Lifecycleby Lipner & Howard y p17 19. Secure Development Principles SD3: Secure by Design, Secure by Default, and in Deployment Learn From Mistakes Minimize Your Attack Surface Assume External Systems Are Insecure Plan On Failure Never Depend on Security Through Obscurity Alone Fix Security Issues Correctly 18 20. Secure Development Practices Threat Modeling / Architectural Risk Assessment Education, Education, Education Secure Coding Via standards and practitioner knowledge Security Reviews A hit tArchitecture Design Code Security Testing (Penetration Testing)19 21. Microsoft s Microsofts Secure Development Lifecycle (SDL) Requirements Design Implementation Verification Release (Waterfall!)20 22. Dr. Dr Dobbs says Agile Methods Are Catching On 41% of organizations have adopted an agile methodologyOf the 2,611 respondents doing agile pg g 37% using eXtreme Programming 19% using Feature Driven Development (FDD) 16% using SCRUM 7% using MSF for Agile S ftif A il Software DDevelopmentl t Source: http://www.ddj.com/dept/architect/19180016921 23. Agile Teams are Quality Infected 60% reported increased productivity 66% reported improved quality 58% improved stakeholder satisfaction 22 24. Adoption Rate for Agile Practices Of the respondents using an agile method 36% have active customer participation 61% have adopted common coding guidelines 53% perform code regression testing 37% utilize pair programming 23 25. An Integrated ProcessMaking Agile Trustworthy24 26. Project Roles Product Manager / Customer Program Manager / Coach Architect Developer Tester Security Adviser25 27. Organization Setup Education & Training (include Security) Developers Testers Customers User Stories / Use Case Driven Processes Enterprise Architecture Decisions Organizational adoption of Threat Modeling26 28. Project / Release Planning User Stories / Use Cases Drive Acceptance Test Scenarios Estimations may affect priorities and thus the composition of the release Inputs for Threat Modeling pg Security Testing Scenarios Determine the qualitative risk budget Keep the customer involved in making risk tradeoffsp g Finalize Architecture & Development Guidelines Common Coding Standards (include security) Crucial for collective code ownership p Data Classification standards Conduct Initial Threat Modeling (assets & threats) Agree on STRIDE and DREAD classifications Designers Security Checklist 27 29. Iteration Planning 1-4 Weeks in Length (2 weeks is very common) B i with an It ti Pl Begins ithIteration Planning M tii Meeting User Stories are broken down into Development Tasks Developers estimate their own tasks p Document the Attack Surface (Story Level) Model the threats alongside the user story documentation Crucial in documentation-light processes documentation light Capture these and keep them Code will tell you what decision was made, threat models will tellyou why decisions were made Crucial for refactoring in the face of changing security priorities Never Slip the Date Add or Remove Stories As Necessary28 30. Executing an Iteration Daily Stand-ups Continuous Integration Code Scanning Tools Security Testing Tools Adherence to Common Coding Standards and Security Guidelines Crucial for communal code ownership Developers Checklist 29 31. Closing an Iteration Automation of Customer Acceptance Tests Include negative testing for identified threats Security Code Review Some may have happened informally during pair programming 30 32. Stabilizing a Release Schedule Defects & Vulnerabilities Prioritize vulnerabilities with client input based on agreed-upon STRIDE and DREAD standardst d d Security Push Include traditional penetration testing31 33. Compromises Weve Made Security Compromises: Short term, iterative focus removes top down control Focus on individual features can blind process to cross-feature security issues Agile Compromises: More documentation than is required in pure Agile development Security coding standards Data classification standards Project-specific STRIDE and DREAD standards User story threat models Additional tasks increase development time Forces customers to accept security (isnt this a good thing?)32 34. Characteristics of an Agile and Secure Process Customer-focused C t fd Responsive Iterative Trustworthy 33 35. Questions Dan Cornell dan@denimgroup.com (210) 572-4400Website: www denimgroup comwww.denimgroup.com Blog 1: www.agileandsecure.com Blog 2: denimgroup.typepad.com34