Presentation on theme: "Reduce Security Risk in Your Development"— Presentation transcript:
1Reduce Security Risk in Your Development Part II: Creating an Agile SSDLCTrent R. Hein, CCIE, CISSP, ISSMP, ISSAP, CSSA#SecureDev
2What We’ll Cover Today How is secure Agile development different? Creating a User Story with integrated securitySecurity Tasks and TestingManaging security DefectsSecurity architectureAgile Threat Map#SecureDev
3Quick Recap of Session 1 Information security overview What are the most common threats?How to protect sensitive data, both from a methodology and technology standpointStandards and toolsNIST SP A, OpenSAMM, OWASP
4How is Secure Agile Development Different? Traditional / WaterfallAgileSecurity TimingDistinct security-focused project phases, often at beginning and end of projectSecurity skills brought in from outside project, often disconnected from dev/test resourcesSpecific security testing phase, often at end of project.Every iteration considers security, but is not limited by it.Every team member is responsible for security. Security skills are embedded in the team.Hybrid security and functionality testing, throughout project.Security ResourcesSecurity Validation
5Secure Agile Development Guiding Principles Product value improves with security.Security is integral to the product, not an afterthought.Outside security resources (standards, threats, experts) provide background, not a cage.
6Agile security myths - 1Myth: I’m a developer / product owner / scrum master. Security is someone else’s job.Reality: The complex threats facing applications today requires everyone to be thinking about security.Secure business logicSecure coding practicesSecure test methodsSecure data architectureSecure deployment environment
7Agile security myths - 2Myth: Compliance with an Information Security Standard isn’t AgileReality: Compliance with an Information Security Standard, such as NIST SP A, is actually easier in an Agile environment, because “baking in” security in smaller pieces allows for simple compliance test cases and less backtracking
8Secure User StoriesThe #1 tenet of secure Agile development is to “bake” security into every user storyRemember: Stories should be defined such that the lowest level child story can be implemented and accepted in a single iterationAny security component(s) of the story, therefore, must be lightweightWhat is the most basic security functionality required for the story to be compliant?Don’t let security define the user story. Let the user story define the security.
9Great, Secure User Stories (from Write a Great User Story, by Ronica Roth)
10VIDEO DEMO 1VIDEO DEMO – Creating a great user story with security elements included in Acceptance Criteria and Definition of Done
11Secure User Story DON’Ts DON’T change the user story template“As a <user type>, I want to <function> so that <benefit>”NOT “As a <user type>, I want to <function> so that <benefit> and <yadda yadda yadda security drivel here>”DON’T create “Security Epics”DON’T assign secure user story creation to “the security guy/gal”DON’T put technical security tasks in the user story itself.
12Security TasksFor each user story, the Developer should create tasks necessary to meet security acceptance criteriaDeveloper should also detail any security testing tasks, as part of defining all the testing tasks for the storySecurity review may also be added as a task, assigned to a security specialist
13VIDEO DEMO 2VIDEO DEMO – Adding security related tasks and testing to a user story
14Security Defects Security defects may be identified As part of iteration testingAfter product deploymentTagging security defects makes them easier to identify and prioritizeOnce defined, security defects are managed along with other defects as part of iteration acceptance and scheduling
16Security Architecture From The Principles of Agile Architecture byAlex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora
17Security Architecture [..] in the context of secure Agile enterprise software systems, we need both: fast, local control of emergent design so that teams react appropriately to changing security requirements without excessive attempts to future risk proof the system, and global control of Intentional Architecture, the guidance needed to assure that the system as a whole has conceptual integrity and efficacy security. Achieving the right balance of emergent design and intentional architecture drives effective secure evolution of the system [..]From The Principles of Agile Architecture byAlex Yakyma and Dean Leffingwell, with contributions from Ryan Martens and Mauricio Zamora
18Agile Threat MappingAssessment of key threats to business value, process, or data setTied to real-world, known threats – not “theoretical”Communicated to all team membersCompleted by team, not by “security guy/gal”