
okay folks we're going to go ahead and get started um be introducing Josh here who's going to be adding plus 10 security to scrum and agile environment thank you thank you um let me give you a little background about myself I started writing code when I was in Middle School um just de decompiling VB apps and making them work the way I wanted to uh when I got into college that's when I started to get into security doing undergraduate research and cryptography and risk assessments um now I work as an application developer for a state agency um and I've been doing scrum for the past two years so a little bit about what I'm going to talk about just going to kind
of touch on the brief goals of security I know we're all here for security but um just there's two main categories I want to point out then I'm going to give you a 10,000 foot overview of what scrum is uh Define some general terms not really going to be a definition dump um how does scrum agile benefit developers what are the effects on business operations um if development teams and security teams work together um and can't achieve their goals uh what happens uh the security negatives in a scrum and Agile development so they things that might not actually work um so given our original goals how would he how do we actually apply those to scrum our security goals and
then I'll discuss the security development scrum integration so how do we start to integrate development and security together um then finally implementing agile and just strictly scrum teams so the goals of security we have two main highle categories prevention and training and response and integration um prevention and training we have things like defining policies procedures uh help to secure an organization protect day-to-day operations finances um continuous education of General individuals like what you shouldn't do um monitoring the essentials Network Tools helped identify things uh issues inside and outside the network set up mechanisms to implement specific secur security policies so your p r your tfas your um your access controls and response and investigation so responding to alarms
anomalies um well this doesn't look right or investigate things during research or defining if figuring out if something goes wrong so those are two main categories now for the 10,000 foot overview of what scrum agile is um a basic definition would be a scrum is a way for small teams to break a large project into short manageable goals um using one to three one to three week Sprints of time um teams can measure their large projects progress toward completion uh teams can identify specific areas of improvement positive outcomes uh at the very end of each Sprint um so basically you're B you're taking a large project and breaking it into small tiny slivers um some general
terms user stories uh there's spe uh a short def uh description uh for a specific task to get a desired outcome so as X I want y so that Z so as a user I want to be able to log in and quickly print a client report or or as a user a remote user I want to um I want to be able to VPN in and connect from home um grooming so defining the acceptance criteria and user stories of specific tasks so what are the requirements uh Sprint is a length of time to complete various tasks uh one to three one to three weeks a scrum Master is an individual who kind of oversees the
project and Guy guides the teams through the scrum process and removes any blockers that if someone has an issue with a task to not being completed um this the person that should help them do it a product owner that's the person that owns the product a retrospective is uh a meeting run by the scrum Master uh at the end of each Sprint to kind of reflect and allow for discussion of what went well what didn't go well um and focus on things that they can improve each week by week um and finally a demo or the demonstration [Music] um that's really how teams uh really demonstrate what they completed the various tasks so what are the
benefits of scrum agile to Developers um helps them to focus on completing assigned tasks during a Sprint during a Sprint um short daily updates are given to complete an individuals um short daily updates are given um in small little meetings by individuals about their specific tasks just to recap either the previous day or what they're intend to work on during the day um discuss any block ERS or issues they might have or foresee to complete a specific task um there's measurable expectations of what they can accomplish on a specific task for defined length of time so when a task task is accepted it's already already has a t already has an estimation um how long you need to
complete that task um after each Sprint the retrospects retrospectives are given to each team um again each team can identify things that went wrong um there's even a rolling record kept from previous Sprints so they can even continue to look back and see if a certain thing is going to be a problem uh requirements and acceptance criteria are clearly defined before each task is actually started um the acceptance criteria can even be adjusted as needed um but only if time allows on the task itself um this kind of limits scope creep of a particular item so if a developer is adjusting the login page you have a set bit of a criteria and you're not going
to limit it's not going to blow up to a huge project um you're able to consistently change Focus so since items are developed in small slivers think of just layers of this large project it's going to Quicken development um since a your acceptance criteria is already set um the the amount of time is already estimated so you're not going to go beyond that so what is the effect of business operations if development teams and security teams can't really achieve their goals um because security teams need to protect their organizations development teams need to improve maybe modify or even develop new functionality so I'll discuss kind of the pros and cons of each group if they don't meet
their goal so let's talk about the pros um with security you if they do meet their goals you're going to continue to protect secure uh and even protect internal operations um help prevent continue to prevent data loss build on existing policies or improved policies and build mechanisms to help protect business operations so how do we decommission Hardware destroy documents um and even respond to incidents as they occur with development um metrics are Set uh this will help establish indates for business operations um you're going to maximize your development time um you're going to get the most out of your developers more eff more efficient use of a resource better documentation uh more feature complete software um because you'll be able to
groom and have proper acceptance [Music] criteria so what are the effect on business what are the cons um since security is mostly reactive you can't fully plan for some things um when new policies and mechanisms are implemented or created sometimes the proper explan explanation of why something is happening or why something is needs to be implemented isn't really explained to individuals so individuals complain they get frustrated their daily routine is adjusted um and has become more complex [Music] um a lack of funding can sometimes provide inadequate security measures um sometimes even a lack of knowledge is just a danger in itself to expose systems um so if you don't secure an environment could be could lose data interrupt business
operations and sometimes even bad press with developer develop if projects aren't completed on time uh funds could be depleted faster future projects could be pushed back um then a general lack of faith of development or developers can increase and can cause problems so what are the negative the negatives with security that can make it difficult to implement scrum or agile in an environment sometimes teams are limited to a set number of tasks um during a Sprint planning um so this doesn't allow for account for emergencies um because we can't really provide an estimation estimation of the scope of uh a malware infestation um so these Scopes are unknown user stories sometimes since user stories need to be very specific
about what they need to do um sometimes you can't encapsulate that into many aspects of security um so as a product owner I want to stop from getting hacked that's a little too [Music] broad so given our previous security goals how do we apply those to scrum with prevention and training um those can be flushed out and grooming so you can limit the scope of a specific task [Music] um and then figure out if it's proper policy and if it meets the definition of actually finished had a retrospective prevention and training could be Contin could be analyzed by the whole team and figured out if things need to be improved further or if things are completely
wrong with response establishing what you are doing during the Sprint so identifying things that might went wrong in the retrospective and how to fix it and your demo could be um just the the process of your
[Music] investigation so how do we um merge security and development teams and integrate them into to an agile scrum [Music] environment um first we want to start to integrate or by integrating security and development um they can start by sitting in the same scrum meetings um with security you might want to Target a specific development team um if there are multiple teams you might want to focus on only one team at a time or have other people in your Security Group uh attend other teams um security teams might want to attend an agile training uh to further understand the concept of scrum and agile and then actively participate uh schedule meetings with developers uh can kind of teach them and
explain them why something is beneficial [Music] or um meet with the product owner and the scrum master to add these to the backlog and then eventually get them groomed uh some security fixes might not be immediately within the scope of the current project so they might get might not get fixed um as quick as you want um sometimes leaving a idol capacity to allow developers um to handle a crisis or if issues need to be fixed but yet have not been groomed or accepted criteria um or if it doesn't have acceptance criteria um then on to some limitations so if there are multiple development teams I touched on this briefly um but there are limited number
of security teams it could be difficult um to focus on multiple teams um security teams could spread themselves to th um um if new developers come on board and they finally understand what security means um there could be um some developer onboarding that needs to happen so you might have to start back all over again um there also could be a learning curve on the security side and development side um just changing how you do things is sometimes kind of difficult if you've been doing it for so long [Music] um and sort of having a developer write better code or um again changing their daily operations in general or even learning scrum if you've been doing one thing day after day might
be kind of difficult um then adding oscope items to the backlog um that are not within the current scope of the development teams might not get fixed so that might be a frustrating
point so implementing agile and scrum security teams kind of G to give a example on that um so let's say we want to improve the current password authentication to an external website um within the begin we might have various tasks to help get the product the project rolling uh so the product owner will need to break down the current policy and uh in a grooming session um start breaking things up into small sers and tasks will start coming out of that um so finding additional finding previous documentation looking through code um if there's no documentation someone with some technical knowledge might need to join the the product onor um figure out how well the policy
is current working currently working and if it really needs to be adjusted or defined so maybe those are questions or tasks that could be
answered so next we need to start building out our user stories after we see after we start doing our research um for this password authentication and then also building our defining our acceptance criteria um so each part of each user story is will start breaking each part into various user stories and so as we build out these user stories we could get things like as a non-technical user I want to log in or as a user I need to increase complexity of the current password strength by setting a minimum character length or as a user I should not be able to use the same password within the last eight times or as an admin I may may need a stronger password
than traditional [Music] users uh from each story we'll continue to break that down into acceptance criteria um and then from here it'll we'll Define our tasks more clearly um if a task can't be defined in at least a single Sprint um then we need to try and figure out how to break a specific task down further uh because we want small slivers and we want to start building uh layering uh tasks on top into our large project um so this will also help us build us our build our documentation if we previously did not have any so as we're getting our user stories and our acceptance criteria um we'll be able to this is how
we create the documentation if it wasn't there um some other tasks the project might not even be finished once we complete our initial tasks because we might need to go back and validate it um and even just validation against the current system so this kind of the umbrella of our current project that we took on um some additional tasks too that you might consider so we start to
um so again I think I briefly said this was we might need to audit the what we currently have and then as we start to Implement task and finish the project we might need to go back and check is it as strong as we initially thought so just validating that
um so then if we find any issues those are more additional tasks um on the current that are still within the scope of the current project if they're not if they're not within the same um and so so we continue to build tasks on our current project and employee training would also be another task to F to teach people and to build document further documentation on how to use uh the new system that we're building uh and even monitoring my people not logging in properly as well because of it um and I think that's the end of my presentation thanks to Grant and bides does anyone have any questions yeah do you
think like f focusing spe he asked what do I think about specific security user stories um [Music] as long as you're pretty specific about what you're trying to accomplish um and because the example that I gave was red doing the um a website's password authentication um so you would have a lot of uh security specific questions or a lot of user stories in there that might need to be answered or um need to be handled in specific tasks so that kind of makes
sense so quick question for you as a product owner I want to help my scrum teams develop secure code quickly so that we can ship the product on time um how do you avoid Sprint lag like you get with developers to QA where you find bugs in Sprint two that are developed in Sprint one well it seems like if the security team comes along and tests after QA then you get security bugs in Sprint three for code that was developed in Sprint one the developers are already on thinking about Sprint 4 you see where I'm going with this yeah so yeah so you said the developers start push everything out to QA and then QA Reinventing waterfall in the security
perspective um that's a difficult question to answer um I think that kind of goes that does go back to some some education um and that is a lot of waterfall if you're going back to initial if you're going back to previous Sprints to fix things that that developers have moved on and sometimes if they didn't comment their code they might not remember a specific problem so I think having everything pretty close-knit um might help resolve that so instead of having a PS um between developers projects they don't they don't really move until they don't move on to the next project until everything's finished hey I was just going to respond but um wouldn't a better approach be
start integrating your security tests into your unit functional testing so you're getting the feedback at the time when the QI testing is actually happening that's also possible as well so my comment is have you tried threat modeling as a kind of a way of kind of injecting those tasks in your have I tried I'm sorry what threat modeling um or threat analysis I have not specifically yeah because I think that's the one way of of kind of concretizing those those tasks and then kind of focusing to the most important kind of items whatever the system is it's a good [Music] point um any other questions well thank you very much