How to Build an Effective InfoSec Risk Management Program

[Music] Higher performance communication resources and faster and more reliable technology. Higher performance communication resources and faster. How to build an effective information security risk management program. And I know this is right after lunch and this is kind of a snoozefest. So, good thing I'm passionate about this. Um, somebody mentioned I have more letters after my name than in my name. Basically, all you need to know about those letters is that I'm qualified to give this presentation. Okay, so goals of an effective risk management program. And you'll hear me say the word effective a lot because there are a ton of risk management programs out there. But what good are they if the people that need to

implement controls don't know why they're implementing them? If you're not matching up with regulatory compliance, if you're not actually mitigating risk in your organization, it's not effective. So, here are the goals. Also, I should get another caveat up front. I put a ton of information in my slides because I'm going to upload them and share them for you. Okay. It's a lot to talk about in an hour. So, don't worry about memorizing what I have on my slides. I'm going to make all those available. Let's just kind of have a conversation about risk management. But the key the goals of an effective risk management program the first is to make sure that the right people in your

organization are making informed decisions about risk. You see a lot that the wrong people are making them or they're making uninformed information decisions about risk. Right? So this is the this is the whole reason that uh that we have jobs in information security. Number two, efficiently analyze risk. efficiently analyze risk based on the data an information system creates, maintains, processes or transmits. That is an effective risk management program strategy. Focus on the data itself, right? Prioritize risk assessment and risk management efforts. Comply with regulatory requirements. Notice I didn't put that first. An effective risk management program mitigates risk. Part of that is compliance. and define an organizational's risk tolerance, right? So, how do you know

you're effectively managing risk if you don't even know what the risk tolerance is of your organization? And often as you're building a riskmanagement program, you won't know until you start issuing risk assessments and getting feedback from your leadership. So, what what are we going to talk about today? We're going to talk about what are the elements of an effective risk management program. Here are the goals, but what do you have to do to get there? First thing you have to do is define what information security risk is. When people hear the word risk, they don't always know what you're talking about. You can mitigate risk in a lot of different ways, in a lot of different

areas. There's insurance liability, there's financial risk. We're talking about information security risk here. You need to set expectations with your leadership. And in in two areas, what is your risk management program and what it is not, right? And where are you in the capability maturity model? You can't go from having zero risk management to having a premier risk management program in a year, right? You have to be able to say this is where we are. This is where we'll be next year. This is where we'll be three years from now. You have to build relationships with key stakeholders. Not what information security people like to do, right? Get out of the basement, start talking to

people. If you don't, there are serious ramifications to the success of your information security program, your risk management program. And you got to talk to these people. You have to talk to office of general counsel, human resources, data stewards, other governance bodies, your peers, your manager right? You need to be able to find the difference between a risk assessment and an audit. Leadership tends to not know the difference. They'll say everything's an audit. you're auditing this system, auditing that system. And it's really important to tell them what the difference is and what you're doing as an information security risk management professional as opposed to internal audit and external audit. Selecting an appropriate framework, you would think that's u, you know, a very

simple thing to do and it's not. And you have to take into consideration what your regulatory requirements are and your organization's culture. You can't just say, "Well, we're just going to adopt ISO 27,0002 as our control framework, right? You have to be able to make sure it's meeting everything that you need." We're going to talk about inherent and residual risk. What is the difference? Why is it important? Why measure both? How does that contribute to an effective risk management program? So, I'm going to go into detail on all of these. So, first thing we're going to do is define risk. What is risk? Risk is likelihood of something bad occurring times the impact of that occurrence.

It is not all impact. And I think sometimes as information security professionals, we hear about malware or particular exploit and we know if it gets in our environment, it's it's really damaging. But you have to ask yourself, how likely is it to happen? That's what is risk. Otherwise, you're just looking at impact, right? And so as professionals we have to do both. You can communicate risk in two ways. Uh quantitative. So you can give them a score and say it's it's a 100 150 somewhere in there. Or you can give qualitative. And I find that the more effective programs actually do both. When you're talking to leadership, you give them a qualitative score. You say

this is a high risk. This is a medium or moderate or low. Right? But when you are talking to auditors, it's always good to have that quantified in some way so that you can say it's it's a medium, but it still ranks within here in a medium. Our medium at the University of Utah scores out quantitatively between 21 and 54 when we do our scoring, right? So sometimes an auditor will want to know exactly what the score is. What are threats? Right? We break our threats out in a natural facility, human adversarial and human non-adversarial. We pulled this directly from Nest. Okay. And breaking out human threats into adversarial versus non-adversial gets people thinking about

the non-adversial vulnerabilities you threats and vulnerabilities you have in your environment, right? People make mistakes and sometimes that can cause a breach or corruption of data. So you have to be prepared for both. uh a vulnerability is a weakness that could be used to endanger or cause harm to an asset. And so we break our vulnerabilities down into technical vulnerabilities is which is what people typically think about in information security, right? You've got weaknesses that are built into the design. It leaves the system open to assault or harm. But what we tend to forget about are the non-technical vulnerabilities that really expose us to risk. And those are effective or non nonexistent policies. I know Jack, Daniel, and then

also the other gentleman that spoke on SDLC earlier talked about you have to document your decisions and communicate what the requirements are. And if you have ineffective or non-existent policies and you don't train people on them, even when your people want to do the right thing, they can pose a risk to your environment. They become a non-technical vulnerability. What are the impacts? Remember, risk is likelihood times impact. the impact to data since we're talking about information security risk management is there's an impact to confidentiality integrity availability right those are the three pillars of information security and really the loss of confidentiality of data is unauthorized disclosure of information it's sharing it outside of your environment or even within your

environment to somebody who's not supposed to be seeing it integrity is when um unauthorized modification or destruction of the information. The data is no longer accurate. You can't trust it. And availability, of course, is the system's not up and available for people who need it. The other impacts that you can consider are agility. And what I mean by agility is the ability for your organization to grow, acquire, innovate. Sometimes if you have information security risks in your environment, you can't do this reputation. there's reputational harm. If you are an information security service provider and you breach data, you're probably going to go out of business. So, there's some things that you have to think about with impact,

right? Again, I like a to see an information system um I'm sorry, an information security risk management program focus on the data. You need to establish a data classification methodology in your environment. Everybody needs to know what you're talking about when you when you say that there are different tiers of data. Here I give an example public sensitive restricted in the environment at the University of Utah. Restricted data is the data that we have apply the most controls to and that includes protected health information, uh PCI card holder data, personally identifiable information and instead of always focusing on the primary data type that your organization likes to uh manage. So, University of Utah, we we have a hospital. So, people

are always saying PHI, PHI. Well, that is a data type that fits into a classification. And we apply controls to a classification of data. Sensitive for us includes student data, maybe internal employee reviews, nothing that have any data breach laws, but we would not want to make public. And then, of course, information that we we feel is is accessible to the public. We want to assign handling rules for those data classification types. What are the access requirements? Do you need to have a non-disclosure agreement? Do you need to have a confidentiality agreement to get to it? Um, what are the encryption requirements? So, you need to establish data classification methodology. You need to understand where does your

data sit at rest and how does it flow within and outside of your organization. If you don't have a basic understanding of of of this, then you're not going to have an effective information security risk management program. Got to focus on the data. Got to have it classified, write rules about it, and know where it is. So, the next thing we're going to talk about is setting expectations. This is probably the hardest work that you'll do as an information security professional. Um, setting expectations and building relationships, right? So the first thing I I always like to communicate to leadership as I'm building a riskmanagement program is what we're talking about in the scope of the risk management program. And I'm

giving you the example of what we set up front on the information security risk management program at the University of Utah. You can have your own elements in here, but it's very clear. You need to be very clear what the expectations are. So our risk management program is designed to communicate information security risk to key stakeholders in a way that's meaningful and repeatable, right? So we need to give them apples to apples comparisons to information systems. So we're going to assess them the same way in a repeatable process and the results need to be meaningful to them so that they can take action. It needs to be focused on data and information systems. It's documentation

and interviewbased. And I'll get into the difference between risk assessment and audit. But this is a big thing here. When it when you're conducting risk assessments, you can't always also be doing evidence collection and sampling or you'll never get through the program. It's going to be aligned with regulatory requirements and industry regarded best practice. And it's a living process that's flexible because there are always new threats and vulnerabilities every day. We can't keep up with them. So you can't have a static riskmanagement program that you implement and five years later it's exactly the same. In the University of Utah, our risk management program currently is not an audit program, a vulnerability management program, which is a mistake a

lot of organizations make. They scan for vulnerabilities, they remediate them, they patch them, they say they have a risk management program. Vulnerabilities are one piece of risk. It's not threat modeling. Although we may leverage groups that do threat modeling to help us give our leadership the information they need to make riskbased decisions, threat modeling in and of itself is not a risk management program. It's not asset management. Although we will ask control questions about managing assets. It's not static and it is not all-incclusive from the first phase. Remember, we're talking about setting expectations. And I see a lot of risk management programs fail because they get challenged right off the bat. Well, if we can't do all of this from day one,

why bother? Well, because when you're managing risk, it doesn't have to be 100% perfect. 100% of the controls don't have to be in place. It's about risk management and you don't have to incorporate everything right off the bat. So some things that you can add on and this is what I communicated to our leadership. Some things that we could add on as we become more mature as our risk management program is going and working. We could add in architecture assessments, platform assessments, more threat modeling, medical device assessments, thirdparty risk assessments. These are all really important, but you can't do it all on the first day. So that setting expectation up front is really critical. I like to leverage the capability

maturity model. It's been around a long time. Why reinvent the wheel? Right? There are five levels. The capability maturity model for anybody who is not familiar with this level one initial, then you move to repeatable process, then a defined repeatable process, a managed defined repeatable process, and you move to optimize. So kind of looks like this. You can find this um this initially this capability maturity model was for software development but it's been adopted through across all IT projects risk management everything and it's really wise to leverage this rather than do your own thing. Sounds like we've got some background music. That's awesome. Making this more exciting. All right. So chaos is level one. This is where we were and

this is where most organizations are. If you're being asked to build a risk management program, it's because it's in absolute chaos. That means nothing's documented. You're just kind of responding to things as they come in. And uh you might talk to John in information security and he's going to give you one kind of risk assessment and you'll talk to me, Kristen, and I'll give you a different one. And then you might talk to uh Corey, Colby, other people in our department and they'll all give you a different representation of risk. That's chaos. repeatable. Some processes are repeatable, possibly with consistent results, possibly with consistent results. You're going to fail a bit in this, right? But the timeline

target to go from level one to level two is about six to nine months. It depends on your culture, depends on how you're setting these expectations, but that's a reasonable timeline. I can tell you the University of Utah is the most complex environment I've ever worked in and I have almost 20 years of experience in this space. Um, and we were able to do this in nine months. So, this is a reasonable timeline target to go from chaos to at least at minimum a repeatable process. The next thing you want to do is go to to a defined repeatable process. That means capture your program in documentation, right? Show exactly what you're doing. So again

this is defined documented standard processes established in subject subject to some degree of improvement over timeline to go from two to three 6 to9 months. We did it in 6 months. So actually I did those two things in parallel which is also a pretty smart thing to do where you can you can start building the repeatable process and document what you're doing and kind of fail forward fast. Right? So as you're as you're making having some issues, you you change both. You change the repeatable process and update your documentation and you till you get something that's working. Managed defined repeatable process. Here you've got metrics. That's a big big part of a managed process. Um you're you're measuring

risk um and you're measuring your progress in managing risk. timeline target to go from three to four, 12 to 18 months. We're going to hit about the 18 months target and optimized. This is a target that's very, very, very difficult to hit. Okay, so you've got continually improving process performance incrementally, innovative technology changes, um common causes of process variation, so you're doing root cause analysis, things like that. But target to go from level four to five is two to five years and actually it's ongoing. I see I see organizations pop from five back down to four, right? They're optimized and then they realize they've made some mistakes or the risk tolerance has changed. So you have to go back to managed and maybe

even go back to updating your documentation, making changes. So this is a this is a great kind of pie in the sky target. I think if you get to a level four maturity, you definitely have an effective risk management program in place. relationship building. This is all of the smoothing you have to do and your own PR about your program. And the reason this is so important is if you don't take the time to go in through the front door of your organization with your information security risk management program, it will be sabotaged. I've seen it. Right? Office of General Counsel, they can sabotage you. They're also fantastic to work with. Why? They're the only people

in the organization that know what do you have to comply with. I I discovered things at the University of Utah I hadn't even considered before. I had regulatory requirements that apply there that have not applied in banking, manufacturing, or any other industry I'd worked in. State, federal, and international regulations. And some of these are really strange. I don't know any of y'all that have some familiarity with how uh Turkey deals with privacy of data. But as you get to become global and maybe you have students like we do at the University of Utah that come from all over the world, you have to understand what the requirements are to manage their residents data or if they

are in Turkey and accessing our data. Right? We've got to think about these kind of things. Contractual requirements and agreements. They're the ones that are going to help you understand when you need a non-disclosure agreement, when you need a confidentiality agreement, what should that language say, and how do we make sure we get it uh appropriately filed? Privacy implications. They help you determine the risk tolerance of the organization and top down support. And you'll see me repeat this quite a bit. Okay? You want to talk to human resources about your information security risk management program. Why? They understand employee life cycles. How do we onboard people? How do we offboard them? Who gets those communications?

Do we terminate people and disconnect everything or do we still have ongoing relationships? The University of Utah sometimes somebody was employee then they become a student and then they become a professor and the HR can help us understand typical employee life cycles so we can manage risk of those types of employees. attrition expectations. Why is attrition important? When we were talking about threats, one of the adversarial human threats is a disgruntled employee. So, as you're learning how to manage risk in your organization, if you have people like we do on the campus side that work at the university their entire life, they graduate and they work there 32 years. But on the hospital side, we have a high

level of attrition front desk billing people, right? So, we can understand how to manage risk from them. sanctioning. They're the ones that do it. They have the disciplinary processes in place and also top down support. Very critical data stewards. These are the people that are ultimately responsible for the controls they want to apply to their data separate from regulatory requirements. So they they have a risk tolerance for how you manage the data that they are stewards of. You need to understand that as you're implementing your risk management program and what their current risk tolerance is based on maybe where their risk tolerance may be 18 months from now. If you have discussions with people about hey student data today

for example is governed by furpa. Furpa is was written in 1974 maybe 76. It has no security requirements zero. It's 100% a privacy law. But the data steward of student data at the University of Utah is the registar and he wants to treat that data as if it had security requirements and align it more how we protect patient information. So if I didn't understand that and talk to the data steward, I might not be helping manage risk in a way that is acceptable for him. Okay. Data stewards are a great escalation channel. If you have people who are not implementing the controls that they want to be implemented, I promise you if you get it escalated to them, some action

will happen. And again, top down support your seuite, same thing. What is their risk tolerance today? Where would they like to be? escalation channels, top down support, and I guarantee you if they don't know what you're doing with risk management, the first time you present them with a risk assessment report, they're not going to know, they're not going to know what their role is. And also, the first time they get a complaint from one of the IT resources that you're interviewing to ask about risk risk, how they're implementing controls, and they're like, "This is taking too much of my time. Why is information security bothering me with this?" that will sabotage your program. They need to be 100% on board with what

you're doing. Other governance bodies, these are the tricky things, right? Often you have governance committees that have more power as a committee than a single seuite person would. So in our organization, we have two CIOS and they are subject to many governing bodies at the University of Utah. We have one for the hospital and one for the campus side. If you don't introduce yourself to these governance bodies, we have an academic senate. We have all kinds of committees at the University of Utah. If you don't go in the front door with them and you don't understand their structure and role, you may be inadvertently sabotaging your program. They may help define risk tolerance as well.

Okay. Does anybody have any questions about that first bit of setting expectations and relationship building before we go into the the real kind of nuts and bolts of a risk management program? Yes,

I will show you. That's a great question. That's we're moving into. So, first risk assessment versus audit. Tons of information up here. There are a lot of differences but I kind of put in bold the biggest differences to me. So a risk assessment function again appropriate personnel in the organization make informed decisions about risk but the key differences are a risk assessment is documentation and interview based but it's not just a checklist. We ask how you are implementing a required control. Tell me how you do it. Knowledge transfer and awareness occurs during the assessment and is not a conflict of interest. So we use risk assessment interview at time periods to say hey first of all were

youware that aware that this would be a control you would be assessed on and explain to them why those controls are important and then give them some guidance about how they should maybe mature their implementation. It's not punitive and reporting gaps is encouraged. That's the first thing I say when I walk in to do a risk assessment interview for I say I'm not an auditor. We're here to determine what the risk is of this system today. Report that risk to leadership. And guess what? If you have major gaps that need funding, the best way to get it funded is to report it now. The worst way to get it funded is to uncover this in an audit because

audits can be punitive. They can be punitive depending on the scope of the audit for both the employees as well as the organization as a whole. So we don't want that to happen. So we say let's talk about the gaps. Let's let's expose them now before an external auditor comes in. Uh risk assessments. Uh the audit is not cooperative often not full disclosure. How many of y'all have been told okay the auditor's coming in and I only want you to answer a yes or no question. Don't tell them how we're doing it. Say yes or no, right? Because you don't want them to go down a rabbit hole. But in the risk assessment process, we do go

down the rabbit hole. So that's one big key difference. Any knowledge transfer can be considered a conflict of interest. You'll never see an external auditor coach somebody on how they should be maturing their implementation and no scoring. The controls are either in place or they're not and the evaluation is not risk based. From an audit perspective, all controls are required. And from a risk assessment perspective, you want to have enough controls to lower the risk to an acceptable level. Okay. Framework selection. How do you decide? First, you should start with your external regulatory drivers. HIPPA, PCI, state data privacy laws. If you deal with any federal grants, you need to be concerned with FSMA. If you're publicly

traded, Serbane Oxley. Okay, these are some examples. There are many. When you look at I'm going to show you some examples of what some of the external regulatory requirements say you should do in a risk assessment. So HIPPA has some guidance. These are the elements that they expect to be in place. Scope data collection. Identify, document potential threats and vulnerabilities. Assess your security measures. This is all best practice. PCI, they tell you what their requirements are. Okay. They even say some example of risk assessment methodologies they find to be acceptable. Then you take a look at industry regarded best practice. So first external regulatory drivers. Second take a look at industry regarded best practices ISO 27000 series. There's 27,0001

27,0002. There's several, right? Um and just to kind of throw you off if you didn't know it's actually pronounced ISO. It stands for international organization of standardization which is not ISO right the reason it's ISO is because the Greek word ISIS means equal and in and this is an international organization so those this words would be different in different languages just a little tidbit NIST 830 series of special publications are focused on um risk management and the 853 special publication is where you at the control frameworks. The new cyber security framework is being leveraged. Again, that will point to other NIS documents, Kobit and Octave. I don't see these two implemented as often anymore, but they

are still uh industry regarded best practice. I'm just going to kind of go through some of these slides to show you. This is what FSMA's security objectives are. Excuse me. This is how FSMA wants you your entire process to run a risk management pro uh framework. You need to categorize your systems, select controls, implement those, assess them, authorize the system, and then monitor the security state moving forward. Excuse me. This is what NIST 830 says your steps should be from a risk management uh flowchart. Oh my gosh, my ear. Sorry. Oh, if you notice, it's all the things we've already talked about, right? Thread identification, vulnerability identification, control analysis, likelihood. The cyber security framework core elements are broken down into five

functions. Identify, protect, detect, respond, recover. It's pretty cool framework if you haven't taken a look at it. This is what the overflow is, the workflow of how to do it. So, external regulatory requirements, best practice. Last thing you want to take a look at to build an effective risk management program is your own organizational culture. What's your business mission? What are you trying to do as an organization? Do you have a single mission or competing missions? Guess what? University of Utah has three missions that often compete. Makes for a complex environment. Do you have any internal regulations that have already been published? These are existing policies and procedures that people need to comply with. What's your risk tolerance?

How do you determine that? Well, you take a look at history. What are some decisions that have been made in the past? You take a look at what is the percentage of budget already currently assigned to information security. Kind of gives you a hint about the importance of information security in your organization today and what's in the news because that's always a priority right? So let's talk about phases of risk management. They're broken down into three. Analyze risk, assess risk, and manage risk. Okay. Risk analysis. You've got inherent risk versus residual risk. Inherent risk is basically the risk an information system poses out of the box before you apply a single control. And this is important to understand so

that you know what controls to apply and how to prioritize full risk assessments. So what we what we assess to determine inherent risk is what types of users will access the system how the system is accessed kind of the architecture and it's very basic the highest classification of data managed the number of users and the number of records. You can see why having that data classification model is so important because it it plays into determining the inherent risk score. Excuse me. We use ranges for a lot of these. So number of users, we don't need to know the exact number of users. We have a range. So like a single department might be 1 to 25 users and that gets assigned

a particular weighted score as opposed to the entire organization which may be over 20,000 users. Right? So we break them up into ranges to score these. Excuse me. Those five questions that we ask actually give you a really comprehensive risk score, right? The likelihood elements or type of users, how the information system is accessed and we break them down into either the information system is on a single workstation. It's on a internetonly client server. it's an internetf facing client server. It's an inter um an internet only web-based application or an internetf facing one. You can see how those would get a different quantifiable score because out of the box no controls in place they pose a different risk. So types of users

architecture classification of data times impact elements number of users number of records and and data. Data is the only one that's in both. It's both a likelihood element because if you have high value data, you're more likely to have that targeted and it's an impact because of the regulatory data breach law requirements. So if that data is taken, then the impact is higher. Residual risk. Residual risk is the remaining risk after you implement the controls. So you've got the inherent risk before we put any controls in place and then you have residual risk. And we we break ours up into uh two different types of control controls to determine residual risk. Entity level controls which are kind of your common controls

for the entire organization. Your HR processes, your policies, your data center, right? Those are going to be the same no matter what information system is in place. And then we ask some system level controls which are operational procedures for that information system. backup and recovery, user identity and access management. This is how we calculate residual risk. So inherent risk score, we give three qualitative assignments. It's either high, medium or low. It's makes it super simple. And we base the residual risk score on a percentage of compliance. So whatever, let's say our well our control set is about 160 controls. So if you have greater than 95% implementation of those 160 controls, you're considered a highly effective system. So if you start

off as high and you have highly effective, we go to medium low. Why not low? We don't believe that you can take a high inherent risk information system to a low residual risk. There's always something residual with regulated data that will never drop you all the way down. But if you have a medium one, highly effective, you can go to a low. So we we tweaked these numbers quite a bit. We ran through we did some tabletop of some of the information systems, right? And we said, well, does this match our gut? We expected this to come out as high inherent risk and be a medium residual risk. And this is tailoring for your organizational culture. There's nothing

that says it has to be 95. Could be 90. Just depends on your environment. And this your question about how do you calculate it's some of the more difficult work that you do up front and I highly recommend table topping it. You tend to know if you pick your, you know, 15 most commonly used information systems in your environment. You probably already have a gut about what you think that they should come out to. Run them through your algorithms and if they don't match, adjust it. It's your information security risk management program and you want it to work in your environment. So adjust these then document it. Okay. Next. So does anybody have any questions

between inherent and residual risk? I do like the where you're talking about effectiveness. Yes. I've seen risk assessment and I never seen Okay. Good. Awesome. All right. So let's talk about risk. Risk assessment. First of all, what's a security control? Right. We talk about controls all the time. Control is a countermeasure to minimize risks to physical property systems or assets. And we tend to break them down into three categories. You have administrative controls that you put in place. That's all your HR processes policy physical controls, and technical controls. After we conduct the inherent risk assessment, that five question survey, and we actually issue it as a survey, we respond with the minimum security control requirements that we expect to

be in place and we can do it within one business day. When we're talking about an effective risk management program, you can't do full risk assessments of every information system coming through your project pipeline before it get goes into production. You can't and if you're a developer, you can't wait on that because the business is saying we need the system out there, right? You want an effective risk management program. As an information security professional, you better be able to communicate risk quickly and this is the way that we do it. We we get the inherent risk survey. Then we immediately respond with minimum security control requirements. They should be mand what are the mandatory baseline controls for all systems. For

us it's unique user ids that you must authenticate a user with a complex password before they access your data that you need to log all user events and retain those logs. Right? What good is it if you have a ton of other controls in place? If your users don't have unique IDs, they're not being authenticated properly. You're not logging what they're doing. when they're in there, you fail. I don't care how strong your perimeter is, right? So, that's what we include. Mandatory controls for all systems. A small subset of the full risk assessment controls are high are our largest subset is 15 controls that we're communicating. They're tailored based on the data type and they are only technical controls.

When we communicate minimum security control requirements, we can't administrative controls are too complex for that. So, we say you filled out the inherent risk survey. told us it had 10,000 users. It has restricted data. It has the types of users or employees, vendor, technical support, students, patients. You um you have over a million data records in the system, right? So, we expect you to have at at a minimum 15 technical controls in place before you can start moving to put this system into our production environment. Why bother? It's efficient and it can be issued via email. It's a great immediate communication of requirements after the survey is complete consistency and we use it for awareness because a lot of IT

administrators and impleers don't read policy but they will read those minimum security control requirements. They'll respond to you and they'll begin to know time over time what our expectations are. So as they're developing new systems they already know what the requirements will be. full risk assessment prioritization. If you want an effective risk management program and you have three people on your team, you cannot do full risk assessments on every system. You can't. So, you want to prioritize these based on the inherent risk score. So, what we prioritize is high inherent risk systems that contain card holder data, protected health information, right? And what are the regulatory drivers? Once we get all the high inherent risk

systems that have our most restricted data, then we can move to medium inherent risk systems that have our most restricted data, then we can move to medium inherent risk systems that contain any data. Right? So, you want to make sure you're prioritizing your efforts. And what can happen is if you haven't built the relationships with those key stakeholders and set the expectations up front, sometimes you get pressured to do full risk assessments on low inherent systems and you can push back and you go, it doesn't matter. They already started off low and even if we ask them 160 questions and they've done none of them, they're still low. So, let's focus on the highs. A full risk assessment should include

those entity level questions and system level questions. Documentation review and interviews with the minimum security control requirements. We issue them to the implement. We let them respond and we move on. We look and see if it's valid and move on. But here we actually do interviews, key stakeholder input. You got to make sure you're interviewing the right people. Why bother? You got to have the full risk assessment to calculate residual risk. Percentage of compliance only applies. Control effectives to residual risk score. It's required by a lot of regulatory bodies. It includes regulatory control sets, best practice control sets, and our tailored controls. Provides leadership with a complete risk profile. Okay, any questions about the types of risk

assessments you can do? Minimum security control assessments and full risk assessments. Okay, both have a place risk assessment summary report. Okay, this is really important. So, as you're conducting a risk assessment, you may be collecting data in mass, right? You may have a spreadsheet or a database that you're keying in how implementers are implementing different controls. You don't want to give that to your leadership. It's too much information for them. You want to issue them a summary report that includes the inherent risk profile in layman's terms. You don't want to just say hi. You want to say this system's inherent risk profile is high because it contains 10,000 users, 100,000 records, these types of records, right? You want them

to understand why you want to have the residual risk profile in business terminology. It started off high inherent risk. They have partially effective controls. So now it is a medium high residual risk. What does that mean to you leadership? It means that we may be out of compliance. We are open to data leakage. You know, you tell them what that score means and what elements impacted the score. Not every control that was failed because sometimes you may have six controls that fail and they all have to do with incident response or they all have to do with backup and recovery. You just tell them we have an immature backup and recovery program, right? And the summary should contain signature

blocks. They need to be signing off on this. And I don't care if it's a wet signature or electronic, but as they read through this, you're going to want them to sign off. Why bother? again informed decisions about risk and consistent communication. We need them over time to be able to look at 50 full risk assessments and understand, hey, every single one of our systems is failing in identity and access management. We're not we're not disabling terminated employees quickly enough. So if they all have this in common, then that they can apply their budget to an a 998 access management program that'll lower the risk of all the information systems across the entire organization, right?

Risk acceptance. What does it look like? Right? It is it looks like a leader going, "Okay, I I understand what you've said in this summary report. I understand that this is still a mediumigh residual risk and we could be out of compliance, but I accept that as long as they're the right person in the organization to do it, that's okay. They just need to sign off on it. It needs to be a formal statement. Why would they not? Why would they accept the risk? This was probably the hardest lesson for me to learn as an information security professional, especially in risk management. I've done a risk assessment. I know there's a ton of gaps. You take it to the leadership

and they go, "That's okay. we don't want to do anything, but there's so many gaps. Well, the cost to remediate may see a benefit of lowered risk in their in their perception, and that's okay. Or they may know that we're in discussions to replace that system, but they can't talk about it, right? They're still in an RFP process. There's some something prohibiting them from discussing it. And I've seen this happen quite a bit. They're just going to flat out replace it. but you don't know that and maybe it's going to be 14 months from now. So, they're not going to pour any money into a system. There are reasons our leaderships our leadership will accept risk and as

long as you as a a riskmanagement professional have given them all the information they need to make an informed decision, you've done your job. And if they formally accept the risk, if something comes back and there's a breach and we told them there were these gaps, then at least we can say we did a thorough risk assessment and we made a mistake. We made a mistake. It wasn't that we didn't know these risks were in place. We just made the wrong decision. That's a different civil money penalty tier. It's different from class action lawsuits for data breach. It's different. So you always want to make careful decisions even if it's the wrong one. Okay. Risk remediation. This is the

most common outcome of issuing a risk report, right? Formal rejection of the current risk score is what you need from your leadership. A target score. They can't just say, "No, we don't like this. Fix it." Okay. We're high residual risk. Where do you want us to go? Because remember, you're talking about percentage of compliance. Well, we want it to be low. Well, it's high res. It's high inherent risk, so it'll never be low. Where do you want it to be? And where do you want it to be this year? And if they say we want to go high inherent risk to medium low residual risk, that may be 40% control implementation that is required to do

that. They've got to apply time deadlines for that. They've got to apply budget. They've got to apply resources. And so you're telling them that they can't just say we reject the risk. Okay, you reject the risk. You want this target score. We need money. We need budget to support this. We need to hire people. We need new tools. We need a new data center. We need whatever it is. And then you get a formal corrective action plan out of that. And then what happens out of the corrective action plan? Well, you need to be updating that. I see a lot of organizations do this. They do the risk assessment. The leadership says, "No, I don't. I reject

the risk." They put together a corrective action plan. They do another risk assessment a year later. All this stuff is still gaps. That's a real problem. So on a quarterly basis, you want to do progress reports and leverage your existing project management programs. You're an information security professional. You're not a project manager. Insert these corrective action plans into your existing project management. Make them projects so they get tracked that way. Then you can just reach out to the project managers. Remember the relationship building those key stakeholders you work with and the top down support. Guess what? If you you go two quarters down the line and you have kind of a rogue IT department, they're not implementing what they're

supposed to do. You start escalating to the data steward and I guarantee you that stuff will get done. Okay, so last 10 minutes just right on time. Common mistakes. Before I move on to this, does anybody have any questions about those three phases? Risk analysis, risk assessment, and risk management. Do you see how the three elements are really important to having a a good comprehensive program? Yeah.

That we we leverage our internal audit team to do that. So that would be sampling or evidence-based, right? As a risk management team, we we we don't have the resources to do that. and we we're trying to build trust and talking about gaps. So, we don't do evidence-based in our risk assessment, but what we do is we issue all of our risk assessments to our internal audit department and they audit the yeses. Anywhere that has uh any of our IT professionals have said yes, we have that implemented, the audit department comes back and they sample those and then that goes in their audit report. So we keep it as separate. That's a good question. Common mistakes. First is IT,

information security or similar offices making risk decisions for the organization. I think there's a huge threat out there. I'm an information security professional. I think there's a huge threat. I recommend a tool to fix it and I pressure to get that purchased and I take up a lot of the budget and maybe it was a high impact threat but not a high likelihood threat const it tends to be something that information security professionals that's a mistake that they make. You you don't have the authority as an information security professional to assume risk for the entire organization. You have the authority to report risk in a way that your leadership can make informed decisions but not to assume it.

You don't have any visibility of business mission changes. You can't anticipate what's coming down the line. Inconsistent risk scoring and reporting. Remember that level one chaos, right? You need to be very consistent so that they can look at all their systems across the board. Compare and contrast. Decide where they're going to apply their money and low likelihood threats not being prioritized appropriately. I know there is some terrible malware out there and there are some very serious malicious attackers, but you have to look at how likely for them to get all the way in, not just the impact of when they do. inefficient and unsustainable processes. If it's not efficient, it won't be adopted and you as an information

security risk management program team won't be able to manage it. Then what happens? You you get this whole effort up and going. You do two risk assessments and that's it. And when I used to be a consultant, I'd see that all the time. An organization has done two risk assessments in eight years because they they they created an inefficient process. failure to consider all of your regulatory requirements up front. Uh guess what? Retrofitting security controls is one of the most expensive things you can do in an information system. And I'm not just talking about money. It it destroys relationships with other teams because they're like, "Why didn't you tell me we had to do this up

front? We wouldn't have selected this vendor. We wouldn't have gotten all the way to production. Now you're delaying our production deployment. You're impacting our business innovation. It's very expensive writing separate riskmanagement programs for each regulatory requirement. Who's seen this? You have a HIPPA program for your PHI and you have a PCI program. Okay, those are not information security risk management programs. Those are compliance programs. And we know that compliance doesn't equal security, right? It's just a checkbox. And there are a lot of things that we do from compliance that does not improve our security posture at all. So you don't want to have your risk management program be a reiteration of the HIPPO security rule or PCIDSS.

That's no reflection of your organizational risk tolerance. Failure to set expectations appropriately too much too soon and misunderstanding the scope of risk management. to your question belit and risk assess at the same time it's too much too soon you won't get anything done you won't get any momentum and momentum is so important because we want to establish that risk tolerance if you only get two risk assessments done in eight years your your leaders aren't going to know you need to be doing at least one full risk assessment a month so over time they can start taking a look at things and over two years they've got 25 risk assessments they can see how corrective action plans have

been implemented over time and they see how the news what's come in the news and what is new from regulatory requirements and decisions they made two years ago might not be the decisions they want to make today. The only way that they can do that is to actually see a collection of full risk assessments inadvertently excluding key stakeholders sabotage your program. That is the number one thing they will do because somebody in there knows the president. I can guarantee you that. And the risk tolerance is unreliable. If you think you've established and you understand what the risk tolerance is and you've left three important key stakeholders out, you don't know the risk tolerance of the organization.

So, does anybody have any questions about uh risk management or any scenarios that you've seen that you want to bring up? Yes. Yeah, KOSO is is more about my understanding of KOSO is it's about how like the seale suite their their operating standards um and KOSO I would not call that an information security risk management framework to leverage KOIT is it was created by Isaka um but it's more operationally focused which is why I choose not to select it but it's common but Koso is more like that that level of operation. Do you have a question?

No, because I I was one person doing this alone for a while at the organization the size of the University of Utah. Okay. But but as we got momentum with the risk management program and they wanted more risk assessments done and more results, we we brought on three more people. Um all of these elements should be done to have an effective risk management program. Even if you only have one system that you assess and you're only your organization's 50 people, if you have the regulatory drivers to do it, then you should do all of these steps. inherent risk, residual risk, risk assessment, summary reports, full interviews, documentation review. Maybe you pick a a smaller full control

set. And we try to keep ours very small. It's that's probably another common mistake is to ask 800 questions in your full risk assessment, right? Who can take any action on that? It's too much. So, we paired ours down to what was important to us. This about 160 controls, but I do think you should run through the whole process. Yes.

Yes. Yep.

Yes.

Right.

Right.

Right.

That's a great question. So, one of the things that we've done at the University of Utah, we're also a government institution. We're subject to grammar, which is the Government Records Access Management Act, I think, is what it stands for. Utah's right to know is what is known here, right? We got this push back all the time. Well, all our employees salaries are public. Why should they be considered sensitive in the data classification model? It's only public after the authorized grammar request has been made. Until it's ready to be public, you have to protect it until that happens. Another great example is publicly traded companies. When the SEC filings go in, all their their financial data is public, right?

Quarterly filings. Before then though, they have to restrict it. So in your in your scenario, is there a situation where you protect it before it becomes public or is it always just public? Yeah that's right.

Right. Right. Yeah.

And that's how I would frame it. Just what I said. So until that formal request is made, your internal classification of data applies and work with data stewards for that. Who is the person in your organization accountable for that data and find out their risk tolerance and then once it's made public through a formalized request it is an external classification of data. That's why that data classification and model is so critical to risk management. Does that make sense? And we can talk after if you want some more clarification. Thank you for your attention after lunch. I didn't see anybody napping. So thank you