Speaker 1: In this video, I'm gonna show you step-by-step and the importance of each of the steps on how to conduct a cybersecurity risk assessment. Coming up. You know, when you think of cybersecurity, there's definitely the offensive pen testing, ethical hacking, there's the blue team sock analyst stuff, but there is another function called GRC, or Governance Risk and Compliance. And it's actually quite important, but it doesn't get as much airtime as the other ones because it doesn't have as much kind of tech built into it, right? And cool demos and stuff like that. Well, within the GRC function, there is a skill or a capability called risk assessments. And it's an analysis type role. And it's important. And you can do a risk assessment of the organization, you can do a risk assessment of a certain solution, you can do a risk assessment on a group of people, you can assess the risk of anything. And the whole point of doing a risk assessment is finding where the vulnerabilities are, the weaknesses, categorizing them so you understand how bad the risks are, and then coming up with remediations or things that you can do to fix the vulnerabilities, or just to reduce the level of impact that those vulnerabilities present if they were exploited. So it's very important. It's an ongoing function within the cybersecurity kind of office or the information security office. And in this video, I've done risk assessments for years, right? And I've gotten some requests from the community. Thank you for providing those requests on how to do this. I'm just gonna shoot from the hip and tell you exactly what you need to know in order to execute a risk assessment. I'll be focusing on an information system because that's more of the common one. Let me introduce myself. If you're new here, my name is Jerry Ozier. This is Simply Cyber. It's a YouTube channel designed to help you make and take a cybersecurity career further, faster. And on this channel, we do all sorts of stuff, how to get into cyber with no experience, how to set up a pen testing lab, and how to do risk assessments, giving that GRC a little love. So that's what we're doing today. If that sounds interesting to you, scroll down, hit subscribe. We push videos at least every Monday. Sometimes we do live streams, kind of renegade style. So stay tuned. If you hit the bell for notifications, you'll be made aware when we go live. So check it out. Use the time markers below to jump around the video or if you come back and you want to get clarity on some particular part, that's what they're there for as a convenience to you. So let's dig into it. Okay, so the risk assessment. It's a pretty standard workflow and you would want to go back to the beginning with some iteration either annually or tri-annually, depending on how large a system it is that you're doing. But basically, let's just take a simple solution. Like your organization or you want to start using Salesforce, right? Salesforce is like a CRM type tool for tracking contacts and stuff like that. Okay, so what is the risk to your organization to start to use that platform, right? This is just an example I'm making up on the fly. Well, first you got to understand, how are we going to use it? What is this system like? So you've got to do data gathering, okay? So because it's a cloud-based system, we're going to reach out to the vendor, right, Salesforce, and get as much information as we can on it. What does the tech stack look like? What is Salesforce like as an organization? What are you guys doing? Do you subscribe to cybersecurity framework? What level are you? Do you get SOC type two audits? Can you provide a recent pen test, right? If it's a cloud-based system, you're going to want them to have some pen testing done, right? So you get as much information on the solution and the company as possible. Think of that as just like data intake for, like, or it's Intel, right? It's intelligence on how you can do something. Secondly, we want to pivot. If you think about it, our organization's going to be using it. How are we going to be using it? Who is going to be using it? Again, it's all about Intel. You cannot do risk analysis without intelligence. What are you basing your risk qualification on, right? So, okay, who wants to, like, who's requesting this? Like, okay, so the CEO. All right, so this is going to be, okay, CEO. Who's going to be using this? Is it just the marketing department? Is it the entire company? Are there third-party vendors involved? Okay, so once you understand what is the use case and try to exhaust all the use cases, right? Because sometimes you'll get a solution, you'll do your risk analysis on it, and there's additional functionality that they didn't even know about that they'll start using. This is why we come back cyclically and look at the products or the enterprise or whatever in order to assess and understand if the risk has changed. Okay, so now that we've got our use cases and we've got our tech stack, what kind of data is going in there? Is it just, is it fake data so we can do simulations? Is it actually our customer client data? Is it data that we have procured from some third party that we've agreed to protect in some way, right? So the government gives data all the time, but there's certain restrictions around how you handle it. What is the data, right? I know we call it cybersecurity, but think for a minute, people. It's called information security, right? Cyber is just a way sexier term to throw around, but like information security is what we're doing. We are securing information. So at the end of the day, the systems are important to protect so they're available to the user base, but the information is what I am concerned with. The confidentiality, integrity, and availability of that information is what I'm protecting. So I need to know what information is it, right? Is it like super secret patents? Is it the Coca-Cola formula? Or is it just public source marketing material, right? The level of control that I need to invest in, both from a financial contribution and a resource perspective changes if the data is less important, right? I don't need to put as much control in. The impact is gonna be less. Okay, so once you get all of that information, you begin to analyze, okay, how do people authenticate to this thing? How do they get access to the system? How is the data brought in and brought out? Is the network traffic encrypted? Is Salesforce required to protect our information? Do they have data at rest? Have they had a breach recently? If we decide to switch from Salesforce to whatever, Oracle, whatever, can we get our data out of there and moved into something else, right? Think holistically about the lifecycle of the use of the system, getting data in, using the data, who has access, who doesn't, and if there's an incident, how that's handled, and then when you wanna terminate the relationship, okay? This is bigger than just tech, right? This is bigger than tech, but there is tech pieces to it. So once you've gotten the whole picture, now you are prepared to do really the risk qualification. There's different ways to do it. This is a qualified risk assessment technique. There is a semi-quantitative risk assessment. There's two techniques, quantitative and qualitative. Quantitative is hard numbers. Qualitative is more like subjective, kind of heat maps and low, medium, high, stuff like that. There is a very popular technique that's growing called FAIR, F-A-I-R, risk assessment, which is more of a semi-quantitative risk assessment technique using probabilities. This is actually quite good, so I recommend you look into that. But once you've got the whole picture, then look at where the weaknesses are. Okay, so they have a mobile app, but it's kind of trashy, or they don't have multi-factor authentication capabilities, or they don't support federated authentication, or they don't have data at rest encryption, okay? Now, some of the controls and some of the weaknesses that are on the cloud side, you're not gonna be able to do with that. You'd have to use other, you can't introduce security controls. You would have to do working into a contractor or whatever. There's mechanisms around that, but identify all your weaknesses, right? So let's just say that they don't support federated authentication, as an example, which means you can't use your organization's username and password to authenticate to the Salesforce platform. Again, this is just a made-up example. I don't know about Salesforce. They probably do have federated authentication support, but so that means that someone has to create local accounts at the Salesforce cloud platform, and all your users are gonna log into that. Okay, so what does that mean? First of all, that means someone has to manage the accounts, right? So everybody that wants a Salesforce account, someone on your end has to be the administrator to go in and create accounts and set them up, and if someone forgets their password, someone's gotta go in and reset the password, right? So that's a level of resource that needs to be considered. Secondly, maybe Salesforce doesn't require strong passwords so that would suck, and it makes the password easy to guess, et cetera, et cetera. So that's a weakness. So once you've identified your weaknesses, then you need to kind of assign a likelihood and impact rating. The likelihood is what is the likelihood of this being exploited, right? And a impact is how bad is it when it does get exploited. To put it in perspective, like the Spectre hardware vulnerability from a couple of years ago, like, yeah, that's really bad, and there's been some proof of concepts and stuff, but the likelihood is wicked low, in my opinion, and I wouldn't really put a lot of resources and effort around protecting and reducing the risk of a Spectre attack, right? That's a low likelihood. Someone getting phished for their Salesforce credentials for a local account, and someone getting into that, that's a pretty high, that's like medium to high likelihood because phishing happens like all the time, like 20% of all attacks start with a phish, right? So that's a bit higher. Now, what is the impact of that? Okay, so let's assume a threat actor phishes you and gets your creds. What does that mean? Well, the impact is that they get access to the Salesforce data. Now, if you've compartmentalized who gets what data, access to what data in there, or the data is like marketing material and not PII, well, then the impact is lower, right? It's not terrible if someone gets in there because it's limited and Salesforce would notify us or we have IP restrictions around where you can log in from. So if it comes from out of the country, it doesn't let you log in right away, right? For example, those are controls. So once you have your likelihood and your impact for all of your known vulnerabilities, then you start to say, okay, like let's categorize these, let's put all the bad ones up here, the medium ones here, the low ones here, and let's present this to management. Hey, management, you wanna go use this platform. These are really bad things that you absolutely need to do. Salesforce, in this example, doesn't support SAML authentication, federated authentication, and they need to. So before we do business with them, because it'll eliminate all those risks I just told you about, before we do business with them, they need to put this in. So then you can start turning the screws to the vendor and say, you guys need to put this in if we're gonna do business together, right? Or they offer either choice, and then you tell your organization, listen, you need to do federated authentication. We cannot use local accounts. The risk is too high. And now it gets into the culture of the organization, tone at the top, how serious are they about cybersecurity? They put it in, the risk is reduced, and you can go a little bit further. So you do that rinse and repeat. A lot of times people will accept the low risks because they're low, but you have that information. And then you can come back a year later, review the system, what has changed, what hasn't, do they offer multi-factor authentication now? Yes, let's turn that on. Just for the account administrator accounts, the end users don't need to do that. They have a mobile app now, so the architecture changes. So yeah, so just be aware of that. So that was a use case example of working through a risk assessment. You'd wanna document in a POAM, a plan of actions and milestones, what those risks are, what the remediations are gonna be, who's gonna be responsible for making the remediations, when those remediations are gonna be made, and then follow up on it. And that's why it's a job, not just analyzing the risk, but actually working through and making sure that the remediations are being done. That is the function of a risk analyst in a GRC capability. Okay, so just in conclusion, get all the intel you can on the system, figure out the use case that the organization's gonna do, identify all the vulnerabilities, figure out the likelihood of those vulnerabilities being exploited, identify the impact to the organization when they are exploited, group them by priority, address the ones that are unacceptable to reduce their risk to a lower level, Rinse and repeat, rinse and repeat, okay? So that's risk analysis, risk assessment. I hope you enjoyed it. I know it was a wicket fest. What I just told you is exactly what it is, but you enjoyed it, hit subscribe if you did. We do videos like this all the time. If you got value out of this, thumbs up and until next time, stay secure. наконец