Welcome to my talk iterative threat modeling enhancing security in agile development little introduction about me my name is Jagdesh Chant, also known as Jax. I'm a full stack developer who plays devsecops role in dev thoughtworks. The paint trip model shows the skill sets I have and the deep knowledge respectively. I always find ways to implement shift security left approach and encourage teams to follow security development. I'm also an OSWe batch holder from offensivesyc along with an AWS security specialist batch. You can follow me in LinkedIn for any security related news and articles. This is the outline of the talk. First we are going to see what is threats modeling, followed by agile threat modeling. Explain with a simulation of how to run the exercise, and finally how to incorporate the same into our agile rituals to achieve iterative threat modeling. Before finishing, we will take a step back and see how to run the threat modeling in different parts of the ongoing project. So first, what is a threat modeling? It's an exercise used to identify threats or different ways to attack a system and model it properly so that the development and operations team can come up with ideas to mitigate it. By doing this proactively, we can prevent the software that we have developed from being compromised by the attackers before it is too late. The traditional threat modeling exercise involves mainly security specialists with very few stakeholders from tech teams development teams. They collaborate, discuss, identify threats and propose a mitigation response plan for it without the development teams much involved. The problem with the traditional threat modeling is that it does not involve development teams and this creates a lot of misconceptions around it. The main misconception is that the penetration revisiting and the code reviews can compensate for threat modeling. These two activities are very effective in finding bugs and making sure the high quality of the software not for security assessment. Threat modeling will uncover design flaws which cannot be identified by these techniques. Without understanding the potential threats an application faces, we cannot ensure in addressing all the risk. And the second misconception is lot of people think that threats modeling can be done after the delivery the software, which is very big red flag. This puts the development lifecycle in a brittle situation where the threat modeling discovers a foundational security threat which requires a rewrite of the entire architecture of the system. And last misconception is that it is too much of time consuming and it is complex. Yes, it is, if you only at a first glance, but if you follow a simple steps, we can achieve threat modeling in a limited time period. These misconceptions created the dawn of agile threat modeling in order to run a threat modeling in an agile software development, we are in need of certain requirements like we need to bring a defensive mindset into the development team so that the development team have the knowledge on security implications. Second, we need to create a collaborative, tailored approach with the development team for capturing threats proactively. A collaborative approach with the business teams so that they can together bring up threats together and leave some space to individual agile teams to tailor the need based upon their working situation. So there should be a space of each agile teams working in an organization to tailor the tune the threat modeling to their needs. And third, one is unawareness. They need to overcome the human errors because of unawareness. This development team should be conscious of the security impacts of the threats, how it is going to affect the business, how is it going to affect a different department from their own box small bubble. They have to think more than their agile teams. The impact is not only to the development but also to the business. And the fourth, a simple exercise which should be introduced at any time of the project and can be repeated iteratively. So keeping the requirements in mind and running trial and errors on various agile teams across thoughtworks. We came up with these five steps of agile threat modelling. It is influenced by the threats modeling framework, but we kept it very simple to run it in any agile environment. The first step is to identify what we want to accomplish in the scope of the exercise, followed by the representation of the scope. Then we brainstorm on the ways that can go wrong. Once we identify what can go wrong, we discuss about the mitigation values and finally we reflect our outcomes of the exercise so that we can do it better next time. We will go through each of these steps in detail in upcoming slides to understand the implementation of the exercise. In the real world scenario, we are going to use the open source juice shop as our guinea pig to simulate the agile threat modeling steps. Little intro about the application the Juice shop is an online website which takes in orders of fresh juice and delivers into your home with a beautiful packaging. Juice shop is the most vulnerable, insecure application available in the Internet so that people who want to practice security, mitigation or security practices, they can use this application as a guinea pig. And this is a high level architectural diagram of the juice shop. We have an front end app, we have a backend juicehop server which runs in a node JS and we also have a payment service node js running in the backend with a postgres database. So few high level legend user data flow is represented in a vector, arrow and authorization boundaries also represents here. So before we get started on our agile threat modeling exercise, we should have a security objective to which everyone should adhere to. Security objective defines the organizational goal towards security, which includes protecting the main assets of the organization like customer data, et cetera. If there is an organization security objective, organizational security objective, we inherit it, else we create a security objective for our scope. It is always better to create a security objective for the organization, but it's not a blocker for our exercise. Security objectives should revolve around the principle of CIA triad. CIA stands for C for confidentiality. Assets which are confidential information should never be compromised. I for integrity of the data should be protected at all costs from tampering. Yay for availability. The service availability should not be interrupted for regular users because of a security threats and it should also answer the following questions. What kind of losses puts the organization objective in geopolitical? Is it having the customer database stolen or a payment? Are we worried about a fraud? Is it malicious insiders or particularly capable hackers? We will try to implement the security objective for our juice shop application. As the juice shop is an online revenue generating platform, the impact to negatively will affect the sales of the shop. We should take care so that the sales of the juice shop is not impacted because of the negative reputation. Secondly, we should reduce the breach of personally identifiable information of the customer, which in turn affects the sales of this juice shop. Third, we should reduce the risk of malicious alteration leading to a financial loss. And finally, the chance of malicious denial of availability of the shop to customer should be reduced. So these are our four security objectives for the Joshop application. So let's start with our first step. What do we want to accomplish? Scoping. This is an important step of threat modeling. We should be very conscious in including the right scoping of the exercise. Always focus on few chunks before performing the activity. Few best practices in creating the scope is whenever a new or upcoming security sensitive feature such as login and checkout flow is coming up, a particular microservice and its collaborating services integrating towards it and high level overview of a system to identify security tech depth. Stop at the integration level. Do not go at the details so reducing the scope, keeping the scope as simple as possible and finally, the continuous delivery pipeline and delivery infrastructure. For our simulation. We will scope the customer login flow as our feature to run our exercises. So we have a customer login epic and the acceptance criteria goes like as a customer I need a page where I can enter login credentials so that I can access the application as a logged in user. We also have a dev story card for it. So this is a new feature that is getting implemented in a beautiful ecommerce juice shop application. So with this we'll go to the second equip representation of the scope. We are going to follow the software centric approach here in a software centric model we represent our systems in a holistic view with the software layers highlighting how data flows from one system to another system using an vector arrows and which is a short form of data flow diagram. The key principle here is to identify the entry points, asserts and trust levels that represent the access rights. You should capture the end to end flow including the external entity where the data flows from for every use case with the system interactions. Of course the key stakeholders during this exercise is engineers which composes of DevOps and as well as the development teams. This is an example of the data flow diagram of the login flow that we are going to create for the juice shop. So here we have three systems involved. The front end app, the back end juice shop server which runs in the node JS and the external identity provider. Here the user when reaches the front end app is redirected to the identity provider. After authentication it provides an authentic code auth code which is sent to juice shop server backend server backend server validates the auth code. If the validation is success then redirects the customer to the home page with the saved token in the session. So this is an overview of the dataflow diagram that we have created for the juice shop login flow. So moving on with this to the third step, what can go wrong here? We are going to evil brainstorm about how the application can produce threats. This is where we wear attackers hat in coming up with ways to attack, break or frustrate a particular bit of software from attackers mindset. The key principle is to be aware of the time and never go into rabbit hole discussion and focus on quantity over quality. Create as many as threats possible without stopping to analyze. Is it really worth or not? And there is a stakeholders involved in this exercise is a security team, product owners from the business and engineers. There are multiple ways or methodologies to implement the evil brainstorming. Starting from pasta, attack trees and waste. Each has their own pros and cons. Pasta is a very good attacker focus but it has a very comprehensive assurance exercise. It is a very long running exercise and we also have a time box strike which is very applicable for agile teams which we are going to be concentrating in this exercise or in this talk specifically this time box stride is very developer focused. What is a stride? It's a methodology to bear attackers hat in different scenarios, different possible scenarios. Walking through and identifying, walking through multiple threats, walking through the different hats of the attacker like spoofed identity and identifying if there is a threat or not and capturing it in our whiteboard or in our beautiful data flow diagram. So let's understand the stride a little bit, what it is, the different hacks of the stride and then try to capture the information s in the stride stands for spoofed identity. It makes us think if an attacker can impersonate someone as using a stolen token, stolen token or a cookies or just brute forcing it. The key concepts is identity and authentication and stakeholders here think through how an application can fail when there is lack of authentication, any form of authentication, tokens or JWT tokens or identifying if you are the real user to do it. Is there a lack of authentication inside the system? And we should also go think through if there is a weakness in the process. The resetting credentials authentication mechanism should subject to brute force attack. Are there any ways attacker can run a brute force attack on login pages? Can an attacker allow you use a very weak password to get into a system or an already compromised password to get into a system? So is there any other way an attacker can spoof themselves as a customer, a legitimate customer, and get into the system? So identifying different ways or scenarios qualifies as a threat. So once you identify a threat, capture it in our dataflow diagram. How do we capture it? We will look into the later slides and moving on in our stride hacks. T in our stride stands for tampering with input e. Here the attacker can go beyond the expected input like giving an hexadecimal URL, encoded values, special characters in login credentials, et cetera. The key concept is validation. Are we doing validation on that unexpected values the attacker is trying to use? What is the integrity of the system? What is the injection? Can the attacker do an cross site scripting? Inject a malicious script inside the client side and run it? Does the validation happens in the front end as well as the back end. These are all the few scenarios and concepts that the stakeholder has to go through before coming up a possible threats inside the system. R in the stride stands for reputation of action. It makes us think if any attacker can do malicious activity and get away without getting a proof of the activity. Key concepts is logging and audit. Is the logs centralized? Is one of the scenarios that we can think through if the logs are centralized. Can the malicious user delete the logs by impersonating other self or escalating using a different credentials? So these are the scenarios that we have to look through or identify in the process of the exercise or give a chance for the stakeholders to come up with the threats. So information disclosure, which is the eye of the stride. It lets us think if the system can give more information what it is supposed to be like. Server versions in the requested headers, response headers, the key concepts is the confidentiality, encryption and leakage. We should not provide an unwanted information when it is not required. Like are we handling the unexpected expression gracefully before sending it to the customer? What's the applications? What happens if you send an unexpected exception back to the user? We disclose if you are using a NoSQL database or SQL database, what is a version of the server that SQL database we are using or what is the type of server we are running with the tech stack. And these are information which are unwanted to the user. So we should able to abstract that information and send it out. So any information which is not necessary to the user should never be given to the user. D in stride stands for denial of service. Can an attacker brings using bots can run and distribute a denial of service so that the legitimate users cannot access the application. Then if they can run it, then it's a threats. The key concepts is availability. Whatever threats that compromises the availability, applications are categorized under denial of service. Finally, e in the stripe stands for elevation of privilege. It makes us think if the attacker can access of files or systems which they should not be. This is also applicable to internal employees. Sensitive files should only be accessed on demand basis. Key concept is authorization isolation remote code execution. Few examples that we can think through is like all the employees, including nontechnical stakeholders have protection edit access. Does all the system have authorization implemented to check the right access of the user before giving back to the user. So we had understood what is the stride model till now and discussed about it. We are going to apply the stride model on our guinea pig juice shop. After applying we come up with lot of threats which is jeopardizing the reputation of action. Like there is no logs for how many unauthorized entries comes in. There can be a brute force attack, there can be a deed distributed denial of service and tampering with the input. There is no strong password configuration in our services and also there is a missing configuration related to elevation of privilege. So these are all the threats that we have identified after applying the stride model. So with this lot of threads in our hand, we move on to the fourth step. What are we going to do about it? We are going to prioritize. This is where the people, the stakeholders owe the riskiest threats. Keeping our security objective in mind, the principle is to use a threats model and the security objective that we have defined in the first step. Using these two techniques, we prioritize the most riskiest threat that we have to concentrate on. What does the dread stands for? The D stands for damage. How bad the damage of the threats is? Is it business as well as the technical how big is the damage? How reproducible is the attack? How easy it is reproducible exploitable? How much work has to be done to launch the attack? Affected users how many people are affected by the impact or impacted by this discoverability? D for discoverability, how easy is to discover the threat? So using the threats model and security objective, we prioritize the cards. The stakeholders who prioritize are the security team, the business stakeholders and the engineers. And how do we this is an example of prioritization of the juice shop that we have done before. The stride model applying the stride model. So here, as you can see, we have two cards, ddos and no strong password configuration. The DDoS is prioritized top because it affects the availability and damages the reputation of the application and it also increases the possibility of the reputation of the juice shop because there is a direct security objective associated with it. We should reduce the malicious denial of availability of the shop and the checkout services to the customers. So that's why the DDoS has been prioritized at the top. No strong password configuration also affects the availability of the application and with a high chance of reproducibility using an already compromised password or easily guessable passwords, the tools available in the market can make sure we run a brute force attack on dictionary attack on the application and get the details out of it once the information, the customer information is revealed. If the password is too much guessable or compromised by the attack, it breaches the personal information identifier information by the customers, which is our second security objective. Based upon this security objective and our dread model, we say that this is a top security threats. Along with this, we have three other no logs about how unauthorized entries APIs are unauthorized. All the APIs are unauthenticated. Storing customer details in JWT as a classified or prioritized threat. After identifying the threat, we are going to mitigate it. How we are going to mitigate capture the mitigation. It can be a tech step user story acceptance criteria or Epics or even a spike to identify if it is a real threats or not. By any one of these methods we capture the mitigation methods that we are going to be applied. The common antipattens is not capturing the mitigations in a project management platform. If you are using a jira, capture the mitigations in the jira not in a spreadsheet or emails, which is not a project management platforms. So you make sure that you capture the mitigations in the project management platforms and prioritizing the mitigations over threats just because the mitigation is a low hanging fruit that should not be done as first. The threat which is more riskiest has to be handled first even though the mitigation is too much complex for it. And this is an example of an mitigating that we applied for our juice shop for the threats identified previously. So we have created a definition of done which makes sure all our APIs are authenticated before the moving the cards to a done. For ddos. We have created acceptance criteria where the attacker IP address has to be rejected if it is found to be malicious and a tech tab for strong password configuration and epic for an logging of the unauthorized entries and finally a spike to see if we are really vulnerable by storing customer details in the JWT. And finally we go into the did we do a good job? Step final fifth step what are we going to do is we are going to reflect ourselves on the outcomes of the exercise. Feedback and continuous improvement is essential to managing risk. Without feedback, we will never improvise or do a better job. The key principle is analyze. Analyzing the scope was the scope too granular? Was it very big? Can we do anything about it or should we not do anything? Analyze the tools used what about the location and remote tools used? Analyze the outcome is a thread discovered where a rare find or just a stones should we tweak the stride model? Should we tweak the examples that is given to the stakeholders? Should we tween about it? Should we work on it or not? That's a way depending upon the outcomes of the exercise you tween and make it better. The stakeholders. Here is security teams and the engineers. Once the reflection is over, we go through the cycle again for every agile sprints or iterations, which leads to iterative threat modeling. How effective is iterative threat modeling? The main hindering factor of running a threat modeling exercise is the alignment between stakeholders like security team, business team and the development team. Each one has their own perspective of security in their mind and agile threat modelling exercise aligns them together is common security goal. This workshop or this exercise should not run more than 16 minutes. In this exercise we align on the factor what is the final destination that we are going to reach or what we want to deliver. We align together on the goal threats, prioritization and the mitigation actions. Once everyone is aligned, it is very easy to repeat and inject into our every iteration. One of the agile rituals is a backlog refining where we refine the stories that are going to be delivered or picked up in the next iteration. We can run the exercise in the same session which should not take more than 15 minutes. By running this using the simple steps in the backlog refining for every iteration, we brings in the security mindset to the development teams and make sure we deliver secure products. Depending upon your team position, you can run this exercise the way you want. If your team sits next to you in the same physical environment, you can run it face to face. The steps is print the cue cards from this presentation, gather everyone against the whiteboard and draw a high level dataflow diagram on the board. Use stickies or sharpies to capture the threats and mitigating save the artifacts digitally, not physically. If the team is hybrid and remote. Take an inspiration from the pdf attached and use any whiteboard presentation in your organization to create the capture the data flow diagram architecture diagram. In this template, use stickies and capture the threats mitigation one important point to running the workshop is be time conscious because you can easily get into a rabbit hole. And if you want to learn more about threat modeling, there are various ways. One is an OASP slack where there are more than 500 threat modelers actively discussing about threat modeling and its future and there is a community in Reddit you can follow for public talks or examples or tools or techniques. In thoughtworks there is a separate blog for security which exclusively talks about threats modeling and the devsecops information. And finally there is a Martin Fowler blog which talks about threats modeling for developers and the links are in the respective blocks. Now that we have gone through the iterative threat modeling for development, let's take a step back and understand how threat modeling is applicable in different stage of projects. When a new project starts, we start with planning stage. We run a business level threat modeling at the requirement gathering stage followed by a high level threat modeling and architectural design stage. Once the planning requirement design happens, we go into a build deploy testing code phase before the deploy and release happens. Build deploy testing in the build deploy testing code we introduce the agile iterative threat modeling exercise. So threat modeling at different stages has different ways or different outcomes. Business level is different from the application threats modeling and delivery or design level is different from iterative or agile threat modeling here. So there are lot of mnemonics in this talk. You might be a little bit confused about what all things let's take a quick recap. You don't need to be a security engineer or expert to run a threat model. Threat modeling will identify threats that you will never find in automation. Threat modeling at any point can be introduced in the software development lifecycle. Extend your existing ways of working and ask what can go wrong? Apply the stride model that is the most quick and flexible way and use the dread and security objectives to prioritize the cards and always create stories, tasks, acceptance criteria or spike never are go outside the project development management tools and don't worry, there is a lot of people out there in the community to help you support. Hope you enjoyed my talk. Feel free to reach to me for any questions related in my link using my LinkedIn profile. Thank you for joining my talk.