Speaker 1: The secret to implementing an appropriate and effective security program is a security risk assessment. Risk assessments are like the blueprints of your security program. They tell you exactly how to build what you need. There's a nine-step process that I use with all of my consulting clients to conduct security risk assessments. And once we're done going through the scoping, the system characterization, the threat identification, vulnerability analysis, control analysis, and all of the other steps, you will have a clear roadmap of exactly what you need to do to make your organization more secure. Here's the thing about cybersecurity. The possible controls that you can implement are endless. It's kind of like a hobby collection. Once you get started, there's no end to what you can do. If you find yourself wondering if you should implement one control versus another, or which solution would give you the greatest return on your investment, you have missed the most essential process, your risk assessment. You see, when done correctly, a risk assessment will tell you exactly which items should be focused on right now, which ones should you do next, and which ones after that. Step one is scoping. Discussing security risks can lead to a ton of rabbit holes. When you set out to begin conducting a security risk assessment, it is very, very important that you clearly define the scope of what you're assessing, what you are assessing, and what you're not assessing. That way, as threat scenarios, vulnerabilities, and the discussion arises, you can clearly delineate between what you are looking at and what you are not, and you can avoid what we call scope creep, where your risk grows and grows and grows and grows to include things that are not necessarily in the scope of this particular assessment. For example, if your security risk assessment is focusing on your website, you are going to create your scope so that that is what you are focusing on. You are not going to wander into the firewall that protects your corporate environment. If your website is solely in the cloud, you're not gonna start talking about endpoint protection, unless maybe you start talking about the developers of the website who are pushing code. You're not gonna start talking about the physical security of your server closet at your building where the website is not stored. That is out of scope for this security risk assessment. The other important thing during your scoping phase is to get buy-in from management. Get their approval on what you're doing, your initiatives that you're taking, and get them on board with this. It makes it a lot easier to get other managers from other departments to participate, create remediation roadmaps after the risk assessment is complete. Get buy-in from executives. Get their approval before you start a big initiative like a security risk assessment. Step two is system characterization. The next step is what I call system characterization, or basically getting an understanding of the environment. What's present? Here's what I want you to do. I want you to create an asset inventory. Some people call this an asset catalog, an identity catalog, whatever you wanna call it. You need to understand what is in the environment that is in scope for the assessment, okay? Back to our website scenario. If the scope is the website that's being assessed, what are the assets in that web environment? Maybe the web server, the web application firewall, any proxies, load balancers, the development environment, if that's in scope, the developers who developed this website, where they're storing the source code, their endpoints, what they're using to develop, et cetera, et cetera. Another important thing is things like application and network diagrams to help you understand the data flow and get a visual understanding of what's happening in the environment. If there's a web application, have diagrams showing the backend, the front end, how those interact, where the database is stored, all of those types of things, those network diagrams, et cetera, those are very, very useful in getting an understanding of your environment, helping you see the broad 30,000 foot view of what's happening. And this is especially important if you bring in a third party to help you so that they can have an understanding of what's happening. Things like data inventories and data maps are another thing to do during this phase. Go through, take a piece of paper and draw two lines, one on the left, one on the right. Leave a little space on either edge. The first line is where data enters your environment. The second line is where data leaves your environment. Let's say you have a website. The website is what's in scope for this risk assessment. What is the data that enters the environment? Maybe you have a contact form. So you'll put a section on the left-hand column, draw a box, and we'll call this the contact form. Inside of that box, write down every piece of information that you collect on that contact form. Name, email address, mailing address if you do, IP address if that's something you collect, et cetera. Now, draw a line through the demarcation line of entering the environment to another box. And this box becomes the web server database as an example. And we're gonna say which of those data points go to the website database, which go to the web analytics system, which go elsewhere. That's one point where data enters. Now, pick another point. Maybe you have a help desk and there's a phone system and people call in to the help desk. They provide information and get assistance. Maybe you collect names, addresses, email addresses, et cetera, via your help desk on the phone. Draw another box on that left side. Fill in the information that's collected via phone calls. And again, draw a line into your environment showing where that data goes. Do this for every possible place where data is collected. Now, we're gonna move to the other side of the page where data leaves the environment. And think about how data leaves the environment. Maybe it's deleted. Do you share any data with third parties? Do you have a contract with another company that's helping you, Microsoft, a third party? Are you storing any of that data in, say, a ticketing system, a third party ticketing system? And now that data is leaving your environment, going to another environment. And again, we're going to draw a line to that box, who it's being shared with. We're gonna list out what data is shared, the reason it's shared, and do that for every place where data leaves your environment. And now, what do you have? You have a data map where data enters, where it's stored, how it moves through your environment. Maybe a report is downloaded with customer names. That goes to a computer. We have all that in the environment section. And we have a leaving the environment section showing how data leaves your environment. Now, you can take all of those data points, put that into an Excel sheet. You have the data point, how it's collected, where it's collected, the reason for its collection, how it moves, and how it's deleted, and how long it's stored. And you have two things, a data inventory and a data map. Because when it comes to security, most of the time, two things we're concerned about. Data and secret information, things like source code, confidential information that needs to stay. Those are two of the biggest things that we're trying to protect. And understanding where that data is, how it moves, is going to greatly help you in securing it. So one of the final things that you need to do during this system characterization phase is creating a vendor inventory. Work with your accounting department. Get a list of everyone you've paid in the last 90 days. Go through this list, which of these are vendors? Which of these vendors do you share sensitive information with? Any of your customer names, anything sensitive, which of these vendors? Or which of these vendors could have access to sensitive information? For an example, maybe you hire a cleaning company. This cleaning company comes on every Friday at five o'clock when you close and they clean your facilities. It's possible they could abuse that access to your facilities to gain access to physical data or to steal information for a competitor, an attacker, et cetera. Go through all of your vendors who have sensitive information, create it, receive it, maintain or transmit it on your behalf, hosting companies, server companies, your MSP if you have one, a managed service provider. Create a vendor inventory that outlines all of that. The point in system characterization is once you complete that phase of the risk assessment, this very, very early phase, you have a very clear understanding of what's happening in your environment, where data is stored, how it moves, who can access that data, who could become potential risk down the road, and you understand what is going on in your environment. Okay, step three is threat identification. At this point in your risk assessment, I want you to think about what are the threats that are applicable to your organization and the scope of what you are assessing in the security risk assessment. There are several threat catalogs that you can use. HITRUST has a threat catalog, NIST has a threat catalog, and it's a very good one. It's free, it's freely available, created by NIST, and it's the one that I'll be referring to in any examples going forward. But the key here is to go through this threat catalog and figure out which ones are actually applicable to the scope of what you are assessing in your environment. So for an example, the NIST threat catalog has a threat scenario discussing wireless network communication interception. If we are focusing our scope of this security risk assessment strictly to a web application, wireless traffic interception in most cases is not applicable to the scope of this risk assessment. Take the NIST threat catalog or whatever threat catalog you're gonna use, go through each one and mark off the ones that are not applicable. We're gonna narrow the scope of what you are assessing to make it more beneficial in the long run. Okay, the next step is vulnerability analysis. But what exactly is a vulnerability? A vulnerability is any weakness in a system or a process that might lead to a breach of information security causing a negative impact on the asset or the organization. Knowing the vulnerabilities for the environment or the asset or whatever is in the scope of this risk assessment is extremely important. It's a very, very important part of being able to identify applicable risk. Let's have a quick example. This is one that I frequently give when I'm talking about risk to clients. Earthquakes. I have a building on the East Coast and a building on the West Coast. As you can imagine, there are different building standards, building codes in California than there are in Florida. Not building the building to earthquake codes could be a vulnerability. In California, that vulnerability of not being equipped to handle earthquakes is a much, much higher risk than it is in Florida where the likelihood of an earthquake happening is a lot less. And there are many ways to go about finding your vulnerabilities. At a minimum, you should really consider conducting a vulnerability assessment, a vulnerability scan, some kind of assessment of what are the vulnerabilities in this application or in the scope of whatever it is you are conducting this risk assessment. If it's an environment, maybe you run an internal vulnerability scan looking for missing patches, misconfigurations, things that could be exploited by an attacker. If this is an external vulnerability scan, maybe you look for open ports, services that are open that should not be. If this is a web application, maybe you look for vulnerabilities in the code, vulnerabilities that could be exploited, SQL injections, cross-site scripting, any of those kinds of things. There are many ways that you can find vulnerabilities. Through audits, through penetration testing, through security analysis like we talked about, automated vulnerability scanning tools. You could look at vulnerability catalogs. The NIST vulnerability catalog, any of the CVS catalogs that have vulnerabilities that have been identified, and you can look if those are present in your environment. Make a note of any vulnerabilities you do have. You can worry about going and fixing them later, and it's important that you do fix them, but make a note of them so that you can consider them when you are determining the likelihood that a threat will have a negative impact on your organization in the following steps. The next step is to analyze your security controls. The next thing you need to do is to investigate all of the security controls in place in your organization, and you can go through and you can try to brainstorm every security control in place, and yes, that's a great thing to do, and you probably should do that at some point. Have your IT team, your security team, make a note of everything they have in place, antivirus, secure configurations, et cetera, et cetera, and so on. However, let's take an organized approach to this, and something I do a lot of times with clients that we're walking through a risk assessment is we will use a security framework. If this organization is in the healthcare space, maybe I use the HIPAA security framework. If this organization is considering SOC 2 compliance down the road, maybe I'll use the SOC 2 framework or ISO 27001. Maybe I'll use the NIST cybersecurity framework. That's a great reference, a very exhaustive cybersecurity framework, or if they're just getting started, maybe I'll just use something as simple as the SIS-20 controls. I'll figure out which implementation level they should be on, and we'll run through the security controls of the SIS-20 for that implementation level. And generally, we will mark the controls as implemented, partially implemented, on the roadmap, not on the roadmap, or not applicable. Each of those gets a different rating based on if they are not applicable, and we will categorize. So we'll take all of the controls related to, say, a hardware inventory, all of the controls related to software inventory, and we'll normalize those scores for each control, and we'll get a category score. Then you can very easily see which security controls you have gaps in, which ones could use additional focus and budget. Another reason I like doing it this way is you get a byproduct for your risk assessment for this step is you have a gap assessment. You have a assessment of the gaps in your security program that you should consider resolving in the future based on the risk for that particular gap. Remember, a security control does not just mean technical security controls, firewalls, antivirus, intrusion detection, and so on and so forth. There are administrative security controls, policies, procedures. There are physical security controls, fences, guards, gates, so on. Now that you understand the security controls, the vulnerabilities, you understand the environment, it's time to move on to threat analysis, and this is kind of a two-step process in analyzing those threats. We talked about a threat catalog. You can use the NIST threat catalog. You could use the HITECH catalog. Whatever threat catalog, even if it's one you came up with yourself, go through each threat and determine the likelihood of that threat and the impact of that threat. The key to a risk assessment is it should be a standard, repeatable process, so you're not taking a guess at this could happen, this couldn't happen, it's unlikely, it's extremely likely. So I like the way that NIST has outlined this. They have outlined likelihood based on if it's been seen by your organization, if that threat has been seen by peers or comparable organization, if that threat has been a warning by industry professionals, if that is a theoretical threat, or if it's not applicable. And using a criteria like this will allow you to come up with a much more realistic likelihood measuring than just trying to figure it out. Remember, as you're determining the likelihood of these security threats, take into account the security controls you have in place. For an example, we'll take the threat of brute forcing. What is the likelihood that someone will try to brute force a web portal that you have? It's very likely. However, if you have a maximum threshold of after five login attempts, the person is locked for X amount of minutes, that is going to greatly reduce the likelihood of brute force happening to almost unlikely. So don't forget to take your security controls into consideration as you analyze those likelihoods. Go back to those threats and analyze the impact. And again, just like with likelihood, the impact measurement should be something methodical and deliberate, not off the cuff and what I believe the impact is. So again, I'm going to refer to the NIST risk assessment methodology and the impact levels that they get. Go take a look at it and use that as your measuring stick. Will it have multiple catastrophic negative impacts on the organization? Will it have a single catastrophic, life-threatening, business-threatening impact on the organization? Will it have moderate negative impacts, minor negative impacts? How those impacts affect the business, help categorize what the impact is. Okay, now you have all of your threats, you have a likelihood assigned, you have an impact assigned. Now it's time to cross those two and figure out what is the risk. So use a risk matrix, or if you have an Excel sheet that you're tracking this in, you could create a formula that will automatically do this for you. We've developed a spreadsheet we use with this formula. If this is high likelihood, high impact, this calculates to a critical risk. Go through each of your threats that are applicable that you reviewed and use the matrix to figure out what is the risk rating for that particular threat. Now, for those critical and high risk items, you may want to consider doing a quantitative risk analysis. What we've described so far is what we call a qualitative risk analysis, not quantitative. With a quantitative risk analysis, you're going to dig a lot deeper into each particular risk to figure out things like how much it would cost the organization for that particular threat to happen, how likely that threat is to happen, what's the timeframe that it would happen, how long does it affect the organization, and then you can get real numbers around. If X threat happens, it's going to cost the organization Y amount of money. That is important when you are taking these findings to management, to the board, to get approval for programs and tools and solutions to resolve some of these risks. You have real numbers, real likelihoods, not just qualitative. Now you have a risk assessment, a risk matrix. For each of those threats, you now understand how likely it is, the impact. You have a risk level assigned to it. Now, take your risk, prioritize the ones that need to be addressed. Maybe it's going to go straight from critical to high to moderate to low, maybe not. It depends on your organization, what the goals are. But take those risks, create a remediation roadmap, which ones you should address first, how you plan to remediate those, and then maybe you can go on to create something like a plan of action and milestones for those risks, how you can measure the progress as those risks are addressed. Then you have something physical to take to the board, showing how you are reducing the risk and the environment of a data breach. If you liked this session of the CISSP Study Corner, please subscribe, like the video, and consider hitting the bell notification so that you're notified when future videos come out. See you next time.