Welcome back. As you are probably aware, when developing software, developers, project managers, and other stakeholders go through a process called the system development life cycle. This process starts off with the most important step, requirements gathering. In the requirements gathering step, stakeholders define and agree on what the system needs to do. This is also where security requirements are defined. In this lesson, we will go through the requirements gathering process using an example system. After this lesson, you'll be able to define security requirements with the help of the stride method, which I'll walk you through in more detail in a little bit. You will also be able to analyze the flow of data and assemble the set of assets that must be secured in a given system. Let me show you what I mean. When developing software, developers, project managers, and other stakeholders go through a process called the system development life cycle. This process starts off with the most important step, requirements gathering. In the requirements gathering step, stakeholders define and agree on what the system needs to do. This is also where security requirements are defined. According to NIST, system development life cycle is the overall process of developing, implementing, and retiring information systems through a multi-step process from initiation, analysis, design, implementation, maintenance, and disposal. In other words, creating software and systems can be broken down into organized phases. In the beginning, we perform a requirements gathering and we want to involve security as early as possible in the project. The goal, in general, is to be able to answer the following. What critical assets and services do we need the system to protect? How should we define user roles? What kinds of privileges to they each have? What is the attack surface of the system? For example, we need to determine points like the API, or, UI, et cetera, where data can be entered or extracted by an unauthorized user. We will now go through the requirements gathering process using an example system. This process is loosely based off of the CLASP security requirements gathering process. The steps that we will go through give a good outline of the security requirements portion of the CLASP process. The general process outline is a following. During requirements gathering, what are the critical assets and services that need to be protected? Are there any user roles with varying privileges? Also, determine where data can be entered or extracted. This is our attack surface. Next, we want to create a threat model. In order to do that, we want to first create a data flow diagram. This involves determining our trust boundaries and we'll get to the idea of trust boundaries in a later lesson. But for now, the next step is, how does data flow from a non-trusted boundary through to various parts of the system. Next, once we have gone through our data flow diagram, we use something called the STRIDE mnemonic in order to determine a list of possible threats and some vulnerabilities to the system. The STRIDE mnemonic stands for: S for spoofing, T for tampering, R for repudiation, I for information leakage, D for denial of service, and E for elevation of privilege. Then based on this threat model that we have created, we want to document our security requirements. The following document is an example Initial System Design. The stake holders for the system have agreed that the functional requirements should be the following. A client makes a request to a server for financial data for a particular banking customer. The server handles the request and fetches data from the backend database. The database response to the request and sends data back to the server. The server response back to the client. We will now go through the security requirements gathering process. From looking at the example system, we can answer the following questions; what critical assets and services do we need a system to protect? First, we need to protect financial data that's stored in the database. Next, we want to be able to protect the requests and responses between the clients and server, and the server and the database. We also want to protect the server resources. The next question is, how should we define user roles? What kinds of privileges do they each have? The initial description is what came out of the stakeholder meeting. They had not yet defined different user roles, but upon thinking through this, they have come up with three user types: regular user, financial administrator, and system administrator. Regular users can only read data from the database, financial administrators can read and write to the database, system administrators can only modify server resources and initiate database backups. The next question is, what's the attack surface of the system? For example, what are the points at which data can be entered or extracted by an unauthorized user? The stake holders would like customers in external networks to be able to access the server. The initial design calls for the server to allow UI and API access via HTTP. From first glance, the attack surface would be via the UI, via the API, and both over HTTP. Here's an example data flow diagram for the system in our example. As you can see, the client is making requests to the bank web server. From there, the bank web server sends SQL queries to the bank database. The bank database responds back by sending over data to the bank web server. Then the bank web server processes this data and sends it as a response back to the client. Now that we've answered those general security requirements questions, we can proceed with creating a threat model of the Initial System Design. As you can see from the previous diagram, the dataflow diagram, we saw how the client and the web server and the database interacted with each other and sent data back and forth to each other. Now, seeing that and more, taking a step back, we add this idea of trust boundaries into that data flow diagram, which is drawn here slightly differently. Now, we're using the idea of trust boundaries for now, but we will go over them in more detail in a later lesson. But when you look at this threat model and its outlining the attack surface of the system, you can see that only the server is placed within a trusted network. Perhaps it is a server placed On-premises. It was decided by the stakeholders that in order to save on maintenance costs, the backend database would be housed in a system in an external network, perhaps a cloud provider. The client making requests sits on an external network, for example, the Internet. So, the data flows from the client side in the external network into the internal system network and reaches the server. The server then makes a request out to the external network to reach the database. Now that we have our data flow diagram and it includes the trust boundaries, we can proceed to use the STRIDE method for creating an initial list of threat vectors. From this list, we can get a general idea of the security requirements that our system requires. Now, this example that I've shown here is a good way of seeing the STRIDE method in action, and we'll go into more detail about the STRIDE method in the next lesson. But for now, I'd like to point out that the STRIDE method is a mnemonic which you can use as a way to brainstorm various threats to your system. S stands for spoofing, which means can a malicious user pretend to be a different user? T stands for tampering. Can a malicious user modified data used by the system? R is for repudiation. Can a malicious user deny that they performed an action to change the system state? I is for information leakage. Can a malicious user extract information that should be kept secret? D is for denial of service. Can a malicious user exhaust system resources such that the system is no longer functioning as intended? E is for elevation of privilege. Can a malicious user increase their ability to work with the system resources? So, in conclusion, we've chatted about the system development lifecycle, and in general the different phases that it has. We've also mentioned that it's best to have the security be part of the lifecycle especially at the initial phase. Most importantly, we talked about data flow diagrams and we also mentioned a little bit about trust boundaries, and using the STRIDE method for threat modeling. In the next video, we will start diving into using the STRIDE method in order to look at a specific example and list out all of the vulnerabilities that we can see, or threats that we can see and the respective vulnerabilities such that we can then prioritize what to fix next. Thank you. See you soon.