• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
OWASPAppSec2006Seattle_AgileAndSecure.ppt
 

OWASPAppSec2006Seattle_AgileAndSecure.ppt

on

  • 699 views

 

Statistics

Views

Total Views
699
Views on SlideShare
699
Embed Views
0

Actions

Likes
0
Downloads
11
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Need a graphic that represents the abstract, can Robot help with this? The Secure Development Lifecycle (SDL) is gaining focus due to: More aggressive regulatory environment (Sarbanes-Oxley, GBL, etc.) are : Increasing the focus on security, requiring organizations to more reliably produce secure “trustworthy” software Traditional approaches are very top-down, document-centric, run counter to agile development practices.
  • Background Goals of Agile (agile manifesto) Goals of SDL Agile Practices in general XP FDD SCRUM SDL Practices
  • Background on my experience with this subject Responsible for oversight and solution architecture review of project delivered by our consulting practice Responsible for oversight and review of application security assessments and development of our mentoring practice for our internal and external presence. This topic / presentation evolved from our own experiences of trying to answer the question of Can We Be Both?
  • These are most of the popular and more widely adopted methods but the list goes on. I learned the other day that Ivar Jacobson has formed yet another agile method which he is calling the Essential Unified Process (EssUP). In a presentation at the Rational Software Developers Conference he stated that “These days to say that you’re not agile is the equivalent of saying that you’re not potent”
  • There are numerous agile methodologies that have been formed (extreme programming, FDD, SCRUM, AUP, Agile MSF, etc.). Each method takes a slightly different approach to the practices they employ to develop software. In 2001, 17 of the thought leaders from XP, SCRUM, DSDM, Crystal, FDD and others met to find a common ground. What emerged from this meeting was the agile manifesto and the formation of the agile alliance. That is to be said that while there is value in the things on the right side, we value the items on the left side more. So we can state that agile methods attempt to be: - adaptive rather than predictive - people-oriented rather than process-oriented
  • Communication: XP and other agile methods aim to keep the right communications flowing by employing practices that can’t be done without communicating. A team of peers facilitates open and honest communication. Simplicity: You’ll here some teams use the phrase, “What’s the simplest thing that could possibly work?” Agile approaches a problem from the position that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used. Feedback flows throughout an agile project and takes place at different levels. Developers get feedback on how well their code is working when they write and execute unit tests. During the planning phases when a customer is defining features, developers will immediately estimate the level of effort so the customer has a better idea on the scope. Automated functional tests provide feedback to the developers and customers that the value defined by the customer is being delivered by the project. ??? Ron Jeffries quote??? Courage is the last of the four core values. Agile projects take courage and a willingness to learn. Altering the architecture in latter parts of the project, throwing code away and starting over,
  • Rapid feedback: The highest priority is to satisfy the customer through early and continuous delivery of valuable software. Simple Design: the right design for software at any given time is the one that: Runs all the tests Has no duplicated logic. States every intention important to the developers Has the fewest possible classes and methods. Incremental change means that the system is developed in small iterations, usually 1-4 week cycles. The releases should be as small as possible. You embrace change by preserving the most options while actually solving the most pressing problems. Agile processes harness change for the customer’s competitive advantage. Everyone likes doing a good job. In an agile model, quality is everyone’s job, every day. Working software is the primary measure of progress!
  • The Planning game - The Customer makes decisions on scope, priority, composition and date of releases. Use cases or user stories describe the desired functionality. Developers provide estimates, consequences, process guidance and detailed scheduling. Shared Vision: All team members (customers and programmers) agree on what they are accomplishing. The customer must be available to the team to answer questions, resolve disputes and set priorities. Small Releases Iterations or cycles in 1-4 week increments Releases as soon as possible.
  • Collective ownership: Anybody who sees an opportunity to add value to the system is required to do so. Test-Driven: Any program feature without an automated test simply doesn’t exist. Continuous integration: the system is continuously built and tested throughout the work day, any build errors or broken unit tests are immediately addressed by the team. Coding Standards: Pair Programming
  • Now let’s change gears for a moment and focus on the Secure side of the equation. I took this statement from the first page of Michael Howard’s Writing Secure Code book. If you ask the customer or business stakeholder on your project, how many of them assume that the developers are going to deliver a system that is secure. It’s quite possibly taken for granted!
  • The next section of this presentation is largely taken from two sources: First, the de facto text for secure development, the “Writing Secure Code” text from Michael Howard and David LeBlanc. Secondly, a paper published by Steve Lipner and Michael Howard to the MSDN Library in March of 2005 entitled “The Trustworthy Computing Security Development Lifecycle”.
  • A few of the principles of secure development include: SD3: Design – means taking the appropriate steps to ensure the overall design of the system is secure from the outset. Default - the system should be secure enough out of the box Deployment – the security of the system should be maintainable once it’s deployed. Assume any data or message you receive from an external system you do not have complete control over to be insecure and a source of attack. What happens if the application is compromised? It’ll never happen is not an acceptable answer. Assume an attacker knows everything you know. When you find an issue, fix it, then go looking for similar ones just like it.
  • An education program is critical to the success of a secure development practices. Without the proper education, the rest of the bullets are on this slide are just the latest buzz words. Threat modeling is the practice of “thinking about the security of your system in a formal way”. The goal is to determine which threats require mitigation and how to carry this out. Secure coding techniques encompass a wide array of software development practices and mindsets that focus on security. Topics such as buffer overflow, access controls, cryptography, input validation, etc. make up this practice. Security Testing is an important part of the overall process. The security tester should be involved throughout the design, development and testing phases. Security Code Reviews are more than ordinary code reviews, they focus on you guessed it security vulnerabilities and common mistakes.
  • Microsoft has modified it’s SDLC to achieve it’s Trustworthy Computing initiative. I’ll review some of the activities performed in each of the phases over the next few slides.
  • Threat Modeling drives the design, code review and testing processes. Threat modeling can then be viewed as the foundation for the SDL, but doing it alone is like doing nothing at all. It is critical that the team follows through on the outputs of the modeling activity. It is all too common that security is added to the project by conducting penetration testing prior to release of the system. This is not a way to achieve security as it is merely treating the symptoms of a broken process. Lastly, using the right tools can enhance a teams effectiveness but you cannot rely on the tools by themselves. They are not going to find everything that experienced, trained developers will.
  • Now let’s divert our attention back to the agile side of the equation for a few moments… In a recent survey sent to Dr. Dobb’s Journal and Software Development readers in March of this year, 41% of the more than 4,200 respondents stated that their organization had adopted an agile development methodology. Over 65% stated that their organization had adopted one or more agile techniques such as coding guidelines, refactoring, automated regression testing and TDD. XP, FDD and SCRUM represent the lion’s share of the methods in use today.
  • A term that has been used to describe agile teams is “quality infected”. 60% of the respondents reported experiencing an increase in team productivity after adopting their respective agile method while 6% reported that productivity was decreased. 66% reported increased quality. 58% reported improved stakeholder satisfaction, 3% reported a decrease in satisfaction
  • While these numbers are encouraging, there is still plenty of room for improvement. I can only speculate that if only 61% of teams have adopted a common coding guideline then where’s the focus on security? Can a team be “quality infected” without having a focus on security? Based on my experience working on agile teams, these numbers seem quite low.
  • This list represents some of the most common and widely practiced methods in use today.
  • The 400lb. Gorilla, the mostly widely adopted method. It seems that several of the agile methods differentiate themselves by stating how they are different from XP. User stories (written by the actual customer) drive the development process.
  • In addition to the standard and accepted project roles, we add the Security Adviser as a member of the team. The Security Adviser would ideally be a full-time member of the team. If this is unrealistic, they must at least be involved in the project from inception to completion and be the go-to resource for the SDL aspects of the process.
  • Most teams new to an agile process will undergo some form of training to get everyone on the same page. This is an excellent time to incorporate security training into the team’s discipline. User stories or use cases are being developed by the customer. The development team is performing architectural spikes and examining applicable frameworks.
  • During the Release Planning iteration, the customer or product managers will be finalizing the initial set of user stories for the release. This process is very much driven by the customer. Developers estimate the level of effort for stories thus potentially impacting the customer’s prioritization and the associated composition of the release. The user stories serve as the basis for defining the customer’s acceptance criteria, these criterion will be used by the tester’s on the project to develop automated acceptance or functional tests to provide feedback that the system is working as the customer expects. The development team (lead by the Security Advisor) will conduct the initial threat modeling and use these outputs to identify a common set of coding standards which include the appropriate emphasis on security. Since attack surfaces may or may not exist, you will not be able to perform the full threat modeling at this point. From the threats, security testing scenarios can be defined.
  • Iteration planning is driven by the developers. The stories or use cases for an iteration are broken down into the development tasks necessary to develop the functionality. Developers have the right to estimate their own work. As the team is discussing the implementation ideas for a story, the attack surface should be captured and discussed as part of this conversation. Agile methods strive to fix dates (and generally resources) then adjust scope as necessary. They believe very strongly in sticking to the original timeline for an iteration. If that means that additional work is added or removed that is perfectly acceptable.
  • Agile teams have a short meeting once a day to keep everyone on the team informed about what’s going. The purpose of these meetings are to communicate problems, not to solve them. For those teams employing the test-driven development practice, features do not exist unless they have an automated test. In XP, all production code is written by a pair of developers sitting at one keyboard. Several of the teams that practice an agile method stray away from this and doing pairing at key times. Our teams pair on a regular basis at two key moments: a) at the outset of a new story b) for large refactorings.
  • Communication: XP and other agile methods aim to keep the right communications flowing by employing practices that can’t be done without communicating. A team of peers facilitates open and honest communication. Simplicity: You’ll here some teams use the phrase, “What’s the simplest thing that could possibly work?” Agile approaches a problem from the position that it is better to do a simple thing today and pay a little more tomorrow to change it if it needs it, than to do a more complicated thing today that may never be used. Feedback flows throughout an agile project and takes place at different levels. Developers get feedback on how well their code is working when they write and execute unit tests. During the planning phases when a customer is defining features, developers will immediately estimate the level of effort so the customer has a better idea on the scope. Automated functional tests provide feedback to the developers and customers that the value defined by the customer is being delivered by the project. ??? Ron Jeffries quote??? Courage is the last of the four core values. Agile projects take courage and a willingness to learn. Altering the architecture in latter parts of the project, throwing code away and starting over,

OWASPAppSec2006Seattle_AgileAndSecure.ppt OWASPAppSec2006Seattle_AgileAndSecure.ppt Presentation Transcript

  • Agile and Secure: Can We Be Both? Dan Cornell, OWASP San Antonio Leader Principal, Denim Group Ltd. [email_address] (210) 572-4400
  • The Agile Practitioner’s Dilemma
    • Agile Forces:
    • More responsive to business concerns
    • Increasing the frequency of stable releases
    • Decreasing the time it takes to deploy new features
    • Secure Forces:
    • More aggressive regulatory environment
    • Increasing focus on need for security
    • Traditional approaches are top-down, document centric
  • Objectives
    • Background
    • Goals of Agile Methods
    • Goals of Secure Development Lifecycle (SDL)
    • Review the Momentum of Agile Methods
    • Look at An Integrated Process
    • Challenges & Compromises
  • Background
    • Dan Cornell
    • Principal of Denim Group, Ltd.
    • MCSD, Java 2 Certified Programmer
    • Challenges facing our own agile teams
      • Deliver projects in an economically-responsible manner
      • Uphold security goals
  • Notable Agile Methods
    • eXtreme Programming (XP)
    • Feature Driven Development (FDD)
    • SCRUM
    • MSF for Agile Software Development
    • Agile Unified Process (AUP)
    • Crystal Clear
    • Dynamic Systems Development Method (DSDM)
  • Manifesto for Agile Software Development
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
    • Source: http:// www.agilemanifesto.org /
  • Agile’s Core Values
    • Communication
    • Simplicity
    • Feedback
    • Courage
  • Principles of Agile Development
    • Rapid Feedback
    • Simple Design
    • Incremental Change
    • Embracing Change
    • Quality Work
    • The system is appropriate for the intended audience.
    • The code passes all the tests.
    • The code communicates everything it needs to.
    • The code has the smallest number of classes and methods.
  • Agile Practices
    • The Planning Game
    • The Driving Metaphor
    • Shared Vision
    • On-Site Customer
    • Small Releases
    • Customer: scope, priorities and release dates
    • Developer: estimates, consequences and detailed scheduling
    • Development iterations or cycles that last 1-4 weeks.
    • Release iterations as soon as possible (weekly, monthly, quarterly).
  • More Agile Practices
    • Collective Ownership
    • Test Driven
    • Continuous Integration
    • Coding Standards
    • Pair Programming
  • Definition of Secure
    • A secure product is one that protects the confidentiality, integrity, and availability of the customers’ information, and the integrity and availability of processing resources under control of the system’s owner or administrator.
    • -- Source: Writing Secure Code (Microsoft.com)
  • A Secure Development Process…
    • Strives To Be A Repeatable Process
    • Requires Team Member Education
    • Tracks Metrics and Maintains Accountability
    • Sources:
    • “ Writing Secure Code” 2 nd Ed., Howard & LeBlanc
    • “ The Trustworthy Computing Security Development Lifecycle”
    • by Lipner & Howard
  • Secure Development Principles
    • SD 3 : 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
  • Secure Development Practices
    • Education, Education, Education
    • Threat Modeling
    • Secure Coding Techniques
    • Security Testing
    • Security Code Reviews
  • Microsoft’s Secure Development Lifecycle (SDL)
    • Requirements
    • Design
    • Implementation
    • Verification
    • Release
    • (Waterfall!)
  • Observations of the SDL in Practice
    • Threat Modeling is the Highest-Priority Component
    • Penetration Testing Alone is Not the Answer
    • Tools Should be Complementary
  • Threat Modeling
    • STRIDE – classify threats
      • Spoofing Identity
      • Tampering with Data
      • Repudiation
      • Information Disclosure
      • Denial of Service
      • Elevation of Privilege
    • DREAD – rank vulnerabilities
      • Damage Potential
      • Reproducibility
      • Exploitability
      • Affected Users
      • Discoverability
  • Dr. Dobb’s says Agile Methods Are Catching On
    • 41% of organizations have adopted an agile methodology
    • Of the 2,611 respondents doing agile…
    • 37% using eXtreme Programming
    • 19% using Feature Driven Development (FDD)
    • 16% using SCRUM
    • 7% using MSF for Agile Software Development
    • Source: http://www.ddj.com/dept/architect/191800169
  • Agile Teams are “Quality Infected”
    • 60% reported increased productivity
    • 66% reported improved quality
    • 58% improved stakeholder satisfaction
  • 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
  • Let’s Look at Some Specific Agile Methods
    • eXtreme Programming (XP)
    • Feature Driven Development (FDD)
    • SCRUM
    • MSF for Agile Software Development
  • eXtreme Programming (XP)
  • Feature Driven Development (FDD)
    • Startup Phase
    Develop an Overall Model Build Features List Planning Design by Feature Build by Feature Construction Phase Source: http://featuredrivendevelopment.com/
  • SCRUM
    • Commonly Used to Enhance Existing Systems
    • Feature Backlog
    • 30 Day Sprints
    • Daily Team Meeting
    Source: http://www.controlchaos.com/
  • MSF for Agile Software Development
    • Adapted from the Spiral / Waterfall Hybrid
    • Product definition, development and testing occurs in overlapping iterations
    • Different iterations have a different focus
  • An Integrated Process
    • Making Agile Trustworthy
  • Project Roles
    • Product Manager / Customer
    • Program Manager / Coach
    • Architect
    • Developer
    • Tester
    • Security Adviser
  • Project Setup
    • Education & Training (include Security)
      • Developers
      • Testers
      • Customers
    • User Stories / Use Case Development
    • Architecture Decisions (spikes)
    • Agree on Threat Modeling standards for the project
      • STRIDE priorities
      • DREAD ratings
  • 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
      • Security Testing Scenarios
      • Determine the qualitative “risk budget”
        • Keep the customer involved in making risk tradeoffs
    • Finalize Architecture & Development Guidelines
      • Common Coding Standards (include security)
        • Crucial for collective code ownership
      • Conduct Initial Threat Modeling (assets & threats)
      • Designer’s Security Checklist
  • Iteration Planning
    • 1-4 Weeks in Length (2 weeks is very common)
    • Begins with an Iteration Planning Meeting
      • User Stories are broken down into Development Tasks
      • Developers estimate their own tasks
      • Document the Attack Surface (Story Level)
      • Model the threats alongside the user story documentation
        • Crucial in documentation-light processes
        • Capture these and keep them
          • Code will tell you what decision was made, threat models will tell you why decisions were made
          • Crucial for “refactoring” in the face of changing security priorities
    • Never Slip the Date
      • Add or Remove Stories As Necessary
  • 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
    • Developer’s Checklist
  • 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
  • Stabilizing a Release
    • Schedule Defects & Vulnerabilities
      • Prioritize vulnerabilities with client input based on agreed-upon STRIDE and DREAD standards
    • Security Push
      • Include traditional penetration testing
  • Compromises We’ve Made
    • Feature-focus in iterations removes some “top down” control
    • More documentation than is required in pure Agile development
      • Security coding standards
      • Project-specific STRIDE and DREAD standards
      • User story threat models
  • Values of an Agile and Secure Process
    • Communication
    • Simplicity
    • Feedback
    • Courage
    • Trustworthy
  • Questions
    • Dan Cornell
    • [email_address]
    • Website: www.denimgroup.com
    • Blog: www.agileandsecure.com