CCT 054: Mastering Threat Modeling: A Guide to Cybersecurity and CISSP Exam Preparation

Welcome to the CISSP Cyber Training Podcast, where we provide you the training and tools you need to pass the CISSP exam the first time. Hi, my name is Sean Gerber and I'm your host for this action-packed, informative podcast. Join me each week as I provide the information you need to pass the CISSP exam and grow your cybersecurity knowledge. All right, let's get started. Hey all, it's Sean Gerber with the CISSP Cyber Training Podcast, and I hope you all are having a beautiful day. It's a great day here in Wichita, kansas, and so we are just in the middle of the United States, if you're just first listening to this podcast and we are having. Actually, it's been very pleasant. It hasn't been a thousand degrees, which it usually is about this time of year, so life is pretty good and we're having a lot of fun here in Wichita. So today we're going to be talking about something called threat modeling. Now, if you're part of the, if you're starting to see the CISSP, this is one of the factors you're going to see within the exam, and they're going to ask you some key questions around threat modeling. I anticipate and threat modeling is something that you're going to use routinely as a security professional and as a CISSP, and so it's important for you to kind of understand that. What is the purpose behind threat modeling? because it does really help drive how you add protections within your company. It also helps you just find how you're going to provide level of risk mitigation and risk knowledge to your senior leaders, because the ultimate goal is, as a security person for a company, you want to be able to provide the best knowledge and experience you can for your company and provide them the information they need to help best protect the organization's data and their various systems. So understanding the threat is really important because, again, it's really hard to protect something if you don't know what are the potential risks against those various systems. And that could be from basically a hacker, it could be from a individual that is looking to get access to your organization. It could be from a specific bad day where you have a straight backcode that's digging out a line and that line ends up snapping and then you have a whole bigger problem. So it's all comes out it could be hurricanes, it could be anything like that. So you really need to understand what is the threat to your organization so that you can best protect the company. So when you're dealing with threat modeling. There's a couple different areas that deal with the definition and how you need to understand it. One is the first one is system identification. Now this involves understanding the system and or the application and how it's tied together on how to best protect it. Now this the other part. When you deal with a system, like you're dealing with a computer itself or you're dealing with the data itself, you want to understand how does it interact with the other systems in that environment. So let's say you have a computer that deals with specifically your information that comes in and it has the pressures, the temperatures, it has the various maybe you have boxes that are sent to a certain location and it measures all of those to know how many went from one place to the next place. You need to know how it interacts with the various other systems. So you may have a forklift that has to go and pick up a pallet of something, but it needs to know it won't go pick up that pallet of whatever your widget is unless it has a certain number of items are actually on that widget or on that pallet. So you need to be aware of how does that actually interact. The other part when you deal with is from a definition standpoint, is also threat identification. So we have system identification and we have threat identification. Threat identification deals specifically with the potential threats that could exploit the vulnerabilities in that system. Now, this could be based on historical data that you may have. It also could be based on intelligence feeds, so you sign up for some sort of intelligence feed that provides you that information, or it could be just theoretical scenarios that you go through in your mind, but you look for what are the potential threats that could be affecting or exploiting that specific system. The next part is a vulnerability assessment. This is where you understand the weaknesses that exist in that system and that could potentially be exploited. So, if you know, for instance, maybe you keep your systems fully patched and they're always updated, but you know that there, because that system is a relatively old device or a relatively old application, it has a very short or very vulnerable password situation. So maybe the password is only six characters, maybe the password can only be numbers it can't be digits or maybe the password is only four characters and maybe it's hard coded into that environment, however, but you know that that system is constantly being patched and updated, but the application itself is vulnerable, so you need to understand some of the vulnerabilities associated with it. The other part is you need to look at a risk evaluation and identify each of the risks that present themselves to that system And then what is the possible likelihood that it could occur to that device, or how, and what is the potential impact based on that happening. The last part is dealing with a mitigation strategy and documentation. So you need to have a strategy that you develop specifically for those threats that you find And if you have that mitigation strategy defined, then when and if that situation does occur, you at least are better prepared for the event that it does happen. So one of the biggest issues I run into is we know there's risks out there for these devices And we know that there's potential hackers could gain access to them. But if we don't document the mitigations around that that because again we're paying attention to it, you're focusing on it And then you document that, it's really hard to protect them, because you're going to get when you, as a security professional, you're going to pass your CISP, you're going to move on to a new company And then you're going to be inundated with ideas and areas that you're going to have to work on to protect your company. So by doing that you're just going to be overwhelmed. So if you're overwhelmed, you don't document those items And then you address one control for one situation, but then something comes up and you move on to the next and you'd forget to document what you needed to do And therefore you might as well just go back and reinvent the wheel again. So it gets a really, really challenging. So it's important that you have all that defined. So now we're trying to understand the importance of threat modeling. There are basically six different areas that you need to be aware of as it relates to that. One is proactive security. Threat modeling does allow your organization to identify and address the security vulnerabilities when you're making that or when you're designing that system, and it really can help you have a more secure environment. It does help you think ahead. Strategic thought process Now, the other part about the CISP is understand that when you answer these questions, you're thinking from a security leader, from management standpoint, and therefore strategic thought process is a key factor in what you should do. It also helps you understand the risks. So you're going to get paid to be a manager of risk, of someone that can then provide guidance and direction to your senior leaders on what is the overall security risk to their organization, and it helps you identify these potential threats, as well as the associated risks that go with it, so that you can focus your security time, energy and efforts on those specific risks. Now you may get to the point where you say you know what, we're just going to accept these specific risks. We're not going to go and do anything more than maybe just go. We know it's there, it's available. I understand that it could affect us, but we're not going to worry about it today. That may be the case. You may just say that's fine, but those are the key factors you, as a security professional, need to be aware of. The other part is security integration. You need to consider how do you integrate these various security mechanisms into the overall development life cycle. Now you're going to find, as you go to a company, there's going to be systems that stay updated, they stay patched, they're constantly considered something that you need to make sure that they're upgraded, like I just mentioned. But there's also going to be systems that you can't touch, and the reason is is maybe they were developed back in the 70s Yes, the 70s And that was before many of you probably listening to this were alive, but they were developed in the 70s and they cannot be messed with because they're. They provide a critical process to that organization And therefore you can't do anything with them. So you may have to deal with. How am I going to handle the security around those systems as well? There's regulatory compliance that may come into where you have standards and frameworks that require some sort of threat modeling or risk assessment. You may work with third parties. So let's say, for example, you are a company that works directly with Walmart or with another large big chain. They may require you to do a certain written manage, a certain framework to be, to be able to utilize them in their business. Why do they require that? Well, because if they know that you are meeting ISO 27001, then that reduces the risk to that company that you could have something happen within your company, within your organization, that would then traverse and go into Walmart or someplace like that. So it's really important to understand you may need to have some sort of compliance around that, some regulatory one, both from a state, federal or from just even a third party vendor. You also need to understand your adversaries. It's really like we mentioned before it's hard to protect something if you don't know who is potentially coming after you And that means that the adversaries it you use. Funny, because, let me, any people will say, well, nation states are after you And that that's great. Which nation states could be? anything and anybody, because we've talked about threats in the past that you have. Typically, you may have an individual that is a lone hacker that's work coming after you for some specific reason, but he or she may also be working specifically with, maybe, a government, because they act as a mercenary, because the talent is somewhat limited on what. Who can really be good hackers? Well, sometimes they will be contracted by companies and or organizations to do corporate, corporate espionage as well. So you need to really understand who potentially could be targeting you and then understand their tactics, techniques and procedures by which they would do this. Now, whether you think the hackers have these TTPs, they do. They have. Some of them may be following very closely. Some of them may be a little bit more loose. However, they do follow some level of technique because, again, as a human, we have a standard way we like to do business. When I was working as a hacker, one of the things was we had a very specific TTP set that we would go against an organization. That didn't mean we didn't think outside the box and change up those TTPs as necessary. However, what it did do was it gave us a standard by which we launched our attacks. If you don't do that, it gets to be you don't. You make mistakes, and when you make mistakes in the hacking world, you get caught. So therefore it's very important that you follow some level of TTPs Communication, education. The process of modeling will also involve multiple stakeholders And from this comes down to architects, to developers. So it's important that you have a way to educate and train people, from security professionals also to business leaders, and that's another factor that you will deal a lot with is communication. As a security professional, you will constantly be talking to business leaders about the threats and then what you can do to make your systems more resilient. So what are some core concepts in threat modeling? So we have the threats, the vulnerabilities and the risks. These are kind of some key factors. So we talked about the threats already. These are potential malicious actors that can harm an information system by altering, disrupting or denying and or degrading the system. They can do this through destroying it by via ransomware. They can do it from actually being on the system and putting a logic bomb in there. They can do many different ways to do this, and so, therefore, you need to truly understand the threat and who are these hacking activists or malware that's potentially evaluating or and or attacking your systems. The clop ransomware is another one that just hit some people recently. You need to really understand how does that act, that piece of malware work against your organization. So if you don't understand how clop works the CLOP, if you don't understand how the clop ransomware works, it's really hard to ensure that you are best protected against it. The hard part is that there's always ransomware coming out or there's always some form of malware coming out, so it's it can be a bit challenging to understand all of it, which you really will never be able to. However, but if you understand the big concepts of what is being used that. Another one is is move it, move it ransomware or ransomware, but vulnerability that came out recently, move it's a remote access to it. Well, if you understand that move it had some sort of vulnerability built into it, you also understand that if you are running on older versions of it, you could be vulnerable. So, therefore, one, you're either remove it out of your environment or two, you then upgrade that system, but you have to be connected with the overall threats that are potentially going to be targeting your environment. Again, talking about vulnerabilities, you need to really understand what are the security vulnerabilities and how you need. People could gain unauthorized asset access to your specific assets And again, this is could be in software, like coding, errors, hardware and even people. Processes are involved in this whole thing. The one thing that you've seen is secrets being stored within your various code repositories. A lot of times this will happen. Many people use code repositories to manage a, to manage a code. So if I have code that's specifically used for an application that I created, i store it out in some various code repository. Maybe it's freeware, then you want to let people use it, but one of the vulnerabilities is that people will store credentials or secrets in these code repositories. Well, that's a big deal. So if you don't have a way to mitigate that, ie, a secure code repository and or not allowing them to do it or create something, that is, they're only allowed to do certain aspects of code, that can be a challenge. So you need to really understand the vulnerabilities associated with it. Risk you also need to understand we talked about what is the loss or damage that's associated with that risk And then the circumstances, condition or event with the situation and how much it could potentially cost you. One example is dealing with various organizations. You may have your business units. So let's say you have a manufacturing facility and this manufacturing facility is in Santiago, chile, and in Santiago, this, this, whatever it makes, whatever widget it makes or however it works, it makes for your company, let's just say, $500,000 a day profit. So just by this company operating in Santiago Chile, it makes your company $500,000 a day in profit. Well, if it's making you that much a day in profit, you want to really understand what are some of the threats that could affect it. Because if your site goes down for two, three, four days a week, 10 days, 30 days, it can have a dramatic impact on your overall bottom line. And when margins are really tight right, most businesses margins are not like super wide. I mean, you think about it, most businesses I operate a business and you're happy, at least in many days, to make anywhere from six to 10% on your margin Businesses you think businesses make a lot of money? they really don't. If they're lucky, they'll make six to 10% in their margin on any given product. So on a half a million dollars a day, that's their profit. Well, if you start losing that, that really cuts into their overall margins for their company, for the, for the month, for the year, and it can be a big deal. So it's important to understand that. Now the components of the Threat Model yeah, your assets, your adversaries, attack vectors and mitigation. So the assets obviously are what? the assets that are out there? they could both be tangible and intangible, which could basically be the intellectual property, is the intangible part of this. Your adversaries obviously the folks that are gonna exploit this. We talked about them already. These also could be disgruntled employees or even the unexpected insiders. So this comes into where you get an employee that clicks on an email. They didn't really intend on it. So the unintended aspect of this and they click on an email and now bad guys are buying, bad girl is able to get into your environment and they are the unexpected or unintended recipient of that. But they could be an insider, they just didn't know it. The various attack vectors how are they coming into your system. How are they going to explode it? and then it could be from a malicious email or it could be from a vulnerable web server that's sitting out on the web. And then the risk analysis and threat prioritization you need to understand the risk and then how do you prioritize it to ensure that you put the most amount of resources that's profitable against that risk. Now, depending upon the company you work for, once you pass the CISSP you're gonna have you're gonna have to determine your company's risk tolerance, and what that means is that how much are they willing to accept when it comes to risk? So let's say, for instance, you work for a company that deals with nuclear weapons. Their allowance for making people making mistakes is extremely low. Right, they have a very low risk tolerance. They will not accept a lot of risk because they're dealing with nuclear weapons. However, somebody that it may be is in a space where they don't really care as much about the overall risk. They do, but it's not as critical as nuclear weapons. And so maybe they make plastic widgets for I don't know toys that go into the cracker jack box, which probably doesn't even exist anymore, but they make little plastic widget toys, things. Well, their level of risk of something bad happening is they're probably more tolerant because that's not a critical business or not a critical piece of their business. So you just have to understand what does your business think about the overall risk to the organization and then how can you deal with it. So we're gonna talk about now some threat modeling methodologies, and you're gonna hear about these in the CISSP exam. One of the things that I'll focus on stride. There's other ones out there, but stride there's another one I wanna talk about too, which hasn't been really brought up a lot, but it is available and I have seen some people deal with that. But we're gonna talk about stride And this is a threat modeling methodology that was developed by Microsoft to help understand security risks. So when you say, well, let's look for risks, well, how can I do that? Well, microsoft came up with this thought process to kind of help you understand what should you do. And so stride is an acronym, that where each letter represents a different category of a threat. So if we're looking at the threat, what potentially could be some of those threats? So the first one is spoofing. Okay, so that's the S in stride. Now this involves where someone pretends, or something pretends to be someone or something right To gain access to, unauthorized access to systems and or the information. Now, this could have happened through websites, emails, ip addresses, people masquerading as someone else. It could be many different ways, but it's called the spoofing piece And that's the S for our stride. The next one is tampering. Now, tampering is where threats will get, will try to accesses or gain unauthorized modifications to a data or the specific system, and this is where the attacker might want to go out there and alter a transaction amount from a financial piece. I would say I looked at this when dealing with EDI transmission. So EDI is your electronic data interchange And this is where banks will send data, will send financial stuff I'd lack of a better word. But if you wanna transfer money from company A to company B, they will send this through an EDI type transaction. And I looked at this from an EDI standpoint of when I was doing risk assessments on various businesses to go okay, well, if someone was able to tamper with that device and were they able to maybe add a dollar to every transaction or $10 to every transaction that was redirected to their bank account, what would happen? Could you do that? Could you pick that up. So that's the tampering piece You wanna try to understand. Can anybody get access to those systems and can they manipulate the data in there? Repudiation this is where threats involve the attack of performing illegal operations in a way that the system cannot prove who performed the action. So this is we talk about this with logging a lot, especially in the CISSP. You wanna have a way to be able to repudiate, to basically be able to say if Sean was tampering with the logs And that's a key factor You wanna be able to prove that it did happen or it didn't happen. And again, i deal, this happens a lot in auditing and assessments. You will look at the logs to see. If the logs are, you can be repudiated. Information disclosure this is where the you don't want the information to be out or people to have access to it. So this is where a confidential email, confidential data, could be read or dispersed based on weak encryption or weak access controls. So that's the information disclosure piece. That's the I in stride. Then D is denial of service. This is where threats are involved in making the system unavailable, unusable. You still see this today. There's various denial of service attacks that occur both from an external point of view and from an internal point of view. So let's say, for instance, you have a scanning tool and you wanna scan your environment. Well, you end up it doesn't go well and it starts causing issues with the internal network. You now created a denial of service. Recently there was a vulnerability with Cisco switches that was out. It kind of went globally and it was a certificate that was tied to those switches that, for basically to help encryption went, got expired And then, when it was expired, it basically broke the encryption. Well, once it broke the encryption, then what ended up happening is is all the service was denied. Therefore, you did a denial of service on yourself. That is the D. E is elevation of privilege. Now, this is where they will. Attackers will elevate their privileges and their permissions to a higher level to ensure that they can gain access to these various systems. They may try to get administrator on this device. They may try to get access to your service accounts. I talk about this a lot. If you have service accounts within your organization which guess what you do You need to make sure that they are being properly protected, because that is one of the key places that hackers will go after Now. What are some of the benefits of stride? Now, it is comprehensive. There are basically there's a systematic approach to having six different ways that you can understand the type of threats, the elevation, all those things. You can decide how you wanna deal with the overall security issues you may have in your company. It is very structured. It is a very structured approach And when you're dealing with security and as many complicated things that are out there, you do want a secured approach to help you deal with the threat modeling process. It integrates well with security development. It does come to sit down a lot when it comes to software development lifecycle. It's tied into that And it does help you reduce the cost and the delays associated with it. It's very educational, which means that it does help you understand and educate people on the overall processes. And there's also tool support. This is Microsoft provides this tool for threat modeling and helps you identify the overall stride process. Now let's go to. That's the benefits. Let's get into the complexities of stride, or the challenges of stride. Complexity, right? So it can be very time consuming, especially if you try to get into a very methodical approach to each risk. It depends on the size of the company that you go work for, running stride against all of the assets it's gonna take. It just isn't doable. So you're gonna have to be able to do this in your head and then start working on the ones that are the most complex in your environment, that are the actually the most work being done. There is some expertise that is needed. It does require a deep understanding of security principles and system architecture. I would say that one thing I learned when I worked as an architect is that it's not as simple as just you can have someone drop them in as a security analyst and say go for it. You really, truly need to understand some of the architecture around it, and this is why I recommend, if you're gonna go work for a company, maybe get make sure that you do some architecture work within that company. If you don't feel like you have a really strong background in architecture, then get smart on it. There's lots of ways you can learn. I would highly recommend that you get some understanding around the network architecture of the organization you go work for Data focus. While stride is good for data flow diagrams and data related threats, it may not be effective when data flow isn't the primary concern. So again, that's an aspect you're gonna need to consider when dealing with stride. It does need to have up to date knowledge. So that means that if you're dealing with old knowledge around these various systems, stride may not be the best for you, but you may wanna go out and find that information rather than just kind of winging it. So it's important to understand that. And then risk prioritization it does focus. Stride does focus on identifying threats rather than assessing or prioritizing them based on the risk. So you're gonna have to kind of stride, you're gonna have to kind of straddle the differences between what stride is putting out and then the overall risk for your company. Now there's another threat modeling product out there, or idea, which is called Trike T-R-I-K-E. Now this one here I haven't seen much of, but it's something to kind of as we're looking from a CISP standpoint. You wanna make sure that you're well-rounded. You have different views because you're gonna be working with teams that are not just a date, one specific group. You could be dealing with anything from trying to secure bed, bath and beyond, to working in a manufacturing facility, to working in a banking system, to whatever it might be. So you need to really understand different types of methodologies out there. So what is the difference with the Trike methodology? Now, trike starts by defining the project's security requirements, and this is specifically set around a project and what needs to be protected and the requirements for that specific asset. Okay, now it's focused on maintaining the CIA triad for that system's data. Now, after you define the security requirements, then you develop this threat model. Specifically, if this includes data flows, access controls, all of those are mapped out with the potential vulnerabilities associated with them. Now, you can see that it's just it's very methodical approach and it deals specifically with the overall project that you're trying to accomplish. Then, once you do that, you accomplish a risk analysis. This is where it identifies the threats that could exploit these vulnerabilities and analyzes these risks associated with these various threats. Now it will use. This model was based on likelihood and obviously an impact to each of the risks of the threats or from each threat, as well, as it does provide a risk rating for each of these. And then you come up with some sort of mis-mitigation strategy to develop this. Now, if you think about this, it makes logical sense, right? You come up with what is the project, what are the threats out there, how is the risk gonna be based on each of these threats against that particular product or project, and then what is the mitigation strength or strategy around that? So again, it sounds very methodical. It's not difficult, right? Well, some of the strengths around trike, and again that's TRIKE. One of the key strengths is that it's a risk-centric approach. So, like we did with stride, it's not so much a risk-based approach, but this trike does help organizations prioritize their security based on potential impact and likelihood of threats. It does align well with concepts of defense and depth. So it does help you think about the different layers of controls when looking at this. And then what are the failure points at each of those layers of controls? That's one of the factors you're gonna understand is, as you get into layers, of defense and depth are important and you need to understand the controls on each layer. But on top of the controls that are there, you need to what are the logging and monitoring aspects that are there to help determine if someone is actually trying to bypass your controls? So that's an important piece of this. Don't just think about, when you're talking security, that I put layer defenses, defense and depth, so you may have a switch in one spot. You may have an application that in that switch you can only gain access to it via X. Then you have a firewall and the only way you can gain access to that is through Y, and then you have the application and the application itself has certain controls that you can only get to. Those are really good. You need that, but you also need to have the ability that you can alert on if you feel that there's something maybe not quite right with that switch or with that firewall. There needs to be some methodology around that. Now, one of the key factors with TRIC is it comes and focuses on the development lifecycle. When I had developers work for me, this was not something that they really truly liked to do. They just actually it's not that they didn't like it, they just in many cases, didn't truly understand it. But it's integrated very strongly in the development space. It does create the software development lifecycle. It's tied into that from the beginning and from. Therefore, it understands or it doesn't understand, but you can understand utilizing that tool. It does provide security considerations as part of the system design rather than an overall afterthought. When you in many cases that's what happens with developers is, they usually get all their development work done. They get it pushed up staging and then they find a vulnerability and then they go back and they have to fix it, or they just push it into production and they don't worry about it. Now, this helps them understand that whole software development life cycle from the beginning. Now, what are the limitations around trike? It does require explicit definition of the security requirements, and so what does that mean? Well, you need to have really good security requirements defined within your project on what you're going to do. So it could be where I have to have a security control in place for this web server. I need to define what is that security control? What are the controls specifically? And then how would they? I would want them implemented within that organization or within that product itself. So you need to have that well defined. It doesn't scale well. Trike doesn't. It can be very labor intensive and time consuming, especially when you're dealing with your developers. Now, a developer their cost dollar per hour is. I mean, if you find someone that's overseas, you could possibly get them at $30 to $40 US an hour. I had some people in Pakistan work on my website and I think that cost me about $30 to $40 an hour, or you can find someone within the United States and that may cost you $170 to $250 an hour, depending upon what you want them to do. So it can be very expensive, but depending upon the risk of your company and the development work that happens, it may be well worth having them use trike because of the fact that you really want to protect your organization, but that because you can see why, because of it's an hourly rate, many times people don't really want people to use have something that slows them down. Hence that would be a bit of a problem. Lack of automated tools, again, like stride, which is much more automated. There are fewer automated tools around trike that support the implementation and the methodology. So you just need to consider that if that's something you may want to do, maybe you come with a version of trike and stride, or maybe you take automated aspects of the stride product and then utilize trike where it's doable. It does focus on data assets, so it is highly data centric, right. So it provides a detailed view of the data related threats and it may not cover them all, but it does go over the overall data and the network infrastructure as well as the physical assets within that environment. There is a skill set that is required. Like anything else, trike does require a team with strong understanding of risk management and threat modeling concepts. So work having developers work for me. They do not always understand this, so it's going to take you as a security professional, potentially, if you want to use trike as a way to walk them through what is the risk profiles for your organization. This is the education part that we want to really talk about the fact that it is a critical piece that you are well integrated within your business teams to understand, to educate and train them on what you expect them to do. That's the other point. Do not anticipate, do not expect that the folks that are going to be working in your organization truly understand security. That is your role. You will be to educate and train them on the basics. That doesn't mean you necessarily train them on everything. Again, you have to teach them to fish not to go out and fish for them, but you will have to teach them how to fish, which that analogy basically means you're going to have to help them do it. So if you don't know how to fish and you don't know how to use a fishing pole and you don't know how to put the worm on the hook. You're going to have to teach them. Okay, this is a fishing pole, this is a reel, this is a hook, this is a worm. This is what you do you put the worm on the hook, you throw the hook with the bobber in the water and then you wait for a fish to bite. You're going to have to teach them that. It's not intuitive, right? I mean, you can kind of figure it out, but it's not the most intuitive thing in the world. So you're going to be required to help teach and train your organization. What are the basics you want them to know around security? Okay, so now I'm going to give you just a case study around how does this work. So the case study is more or less just an example. It's all subjective and it's all thought of right, or it's a made up objective, but you will understand what I'm getting at when I get into it. So let's this threat modeling and how this works in action. We're going to first start with some online banking application. So this online banking is the overall application we're going to deal with. So the first thing you want to do is identify that system. So then this scenario it's an online banking application and you need to understand what is the functionality, the architecture of the application, as well as how does the data flow in and out of the application, and then what are the integration points. So let's just kind of pull that apart a little bit. So we know that there's an online banking application. It is hosted internally. You have your own web development team. You have your own web application that's being hosted in your environment. I know whether it's AWS or whether it's in your data center that you have, but you are hosting your own web app. You then have you know that it's tied into various pieces back into your environment, into your network, and you also know that there's firewalls in front of it that are sitting out there on the internet. But it's, it's facing the internet and it's sitting within your network. So you know that. You know that once the data you come in, you log into the web app, you enter in the information. Once that data is put in there and they hit return, it is then posted to a database that is sitting within your environment, and so now all you can tell that the internet people put data in on a web application. it then dumps into information into your environment And so, and also there's potential API connections with other banks that are tied into this web application as well. So you got now you've got an individual that can log in, that can add data, that can post to a database. you now also have API is that potentially, are communicating back and forth with your web application. So you now understand data flows coming in. You understand what is the application itself. You understand the functionality of it. It's to basically do banking for you can make it up whether it's individuals or for businesses, but there's a way that you come in and you do that. So that's all been defined and structured. So now you know where are all the points and what is your overall function of this system. Now you need to look at the critical assets on where the what's involved. Now the critical assets could be customers, personal information, transaction details, account balances, edi information between banks all of that. That is your asset identification. So you know you have the systems, you know the data that's coming and going. So you now have identified what are these assets out there. Then the next thing you come down to is you look at the threats. What are the threats that could be affecting this one from stealing the information. Right, they can steal the sensitive information. They could try to disrupt your service. They even potentially insiders could use to manipulate the data and send that extra $10 per transaction to their bank account. Or in the case of I can't remember the name of that movie where they would siphon off a penny every transaction. A penny was was sent to a bank account, a Swiss bank account, and then that penny, because it was sent off, because there were so many transactions, those pennies became dollars and those dollars became hundreds and thousands and millions of dollars. So again, you want to understand what is the potential threat to that. Then you want to understand the vulnerability assessment around it. So you know that you need to have authenticated users coming into that environment. Do they have? we talked about having fields where people could add information? So can they have some sort of cross site scripting attack? Could there be a SQL injection? Do you have logging and monitoring on that system so that you can go back and look at it if there's an event? All of those pieces you're getting. You're breaking this thing down from system to asset, to threat, to vulnerabilities, and then you're going to look at the risk. So you go. I had this online system. The risk is there. There is millions of people that can look at this. I look at the logging data of it. I see that there's thousands and hundreds of thousands of people hitting this system, so the risk is going up. It is. I have developers that are in Bangladesh that are working on it. I have, but it's it's hosted in the UK, so that's something you need to understand from a risk point of view. Is there GDPR concerns? Is there regulatory concerns? So you can see all these dynamics are all flowing in to this potential application, and then you want to look at strategy and how to mitigate this overall risk itself. Do you decide you know what? rather than us hosting it within our environment, i want to mitigate some of this risk, so I'm going to move this to a hosted environment within Azure or AWS. I'm going to pay a third party to manage this system for me so that I don't have to worry about maintaining all the infrastructure behind it. So that will help reduce some of my risk. Now, it may reduce your risk or it could transfer your risk to this third party. You need to do a due diligence on this third party to ensure that it is properly protecting your information, so that adds a whole different dynamic. So you pick up and you move this application from your environment to this third party. You now need to do the due diligence of this third party to ensure that they are properly protecting your data, your systems, your critical assets, their asset identification. They're protecting all of that in a way that you would want to do that. And then, lastly, you want to make sure you document all of these steps because, like everything else, you'll get a new job, you'll be moved up in your company, you'll get it, you'll go to a new company, and if you don't have this documented, it will make it extremely challenging for the person who's coming behind you to understand it. Or, in the event that, even if you're working there and something bad happens, you're going to be inundated with security issues, well, what's going to happen is, if you don't document it, you may forget, like I forget. You'll forget. Where did you put these systems, what did I do? How did I deal with it? Documentation is a key factor, and I would say documentation is probably one of those areas that we all fall down in, because it's usually the last step and we get busy and move on to something else And our ADD kicks in and we're like, yeah, squirrel, and we go off to something else. All right, that is all I have today for threat modeling. I want you to go out check out to CISSPcybertrainingcom. Go check out my blueprint. I got an awesome blueprint. One of the key things around taking your CISSP test is you want to be able to have a good plan. You need to have a plan. Well, that plan can come from my blueprint that's available at CISSP cyber training. Go check it out. You'll love it. It's really, really good. All right, that's all I've got for today And I hope you have a wonderful day. We will catch you on the flip side, see you.