The Intersection of Business and Cybersecurity

Cole French:

The cost of cybersecurity implementation is anything but trivial. In fact, the cost is difficult to measure because so much of it comes in the form of time and effort. Cybersecurity is, first and foremost, a people and process problem, not a technology problem. The cost, however, is nothing compared to what cybersecurity failures cost. Numbers that boggle the mind and confound imaginations. Tune into today’s conversation where we reach back to the classroom for a refresher on how to conduct risk analysis that guide good cybersecurity implementations.

Welcome to the Cyber Compliance and Beyond podcast, a Kratos podcast that brings clarity to compliance, helping you leverage compliance as a tool to drive your business’s ability to compete in any market. I’m your host, Cole French. Kratos is a leading cybersecurity compliance advisory and assessment organization, providing services to both government and commercial clients across varying sectors, including defense, space, satellite, financial services, and healthcare. Now let’s get to today’s episode and help you move cybersecurity forward.

As compliance practitioners, we commonly see organizations struggle to conduct proper and thorough analyses of risk. In addition, we also see organizations struggling to navigate the intersection of the business and cybersecurity. The key to success for any cybersecurity implementation is buy-in from business leaders and decision-makers. But a major roadblock to that buy-in is the cost of cybersecurity implementation. Just how do organizations justify the cost? The knee-jerk response is to point out the cost of cybersecurity failures, but that isn’t enough. Knee-jerk responses never are. As we’ll break down in today’s episode, the tension of justifying the cost brings us back to risk analyses and their value in navigating the intersection of the business and cybersecurity.

Joining us today are Dr. Selwyn Ellis and Dr. Jake Lee. Dr. Ellis is the Balsley-Whitmore endowed professor in the College of Business at Louisiana Tech University. He’s the chair of the Department of Computer Information Systems, and director of the Center for Information Assurance. He earned a Bachelor of Science with a double major in mathematics and computer science, as well as an MBA from Mississippi College, and a DBA in quantitative analysis and management information systems from Louisiana Tech University. He has published over 40 articles in various academic journals, including Communications of the ACM, IEEE Transactions on Professional Communication, and the European Journal of Information Systems. His research is mainly in data analytics and behavioral aspects of information technology.

Dr. Jake Lee is an associate professor of computer information systems in the College of Business at Louisiana Tech University. He earned a PhD in management science and systems from the State University of New York at Buffalo. His research interests include information security and privacy, emergency response, cloud computing, and telework. His research has appeared in the European Journal of Information Systems, Information Systems Frontiers, and the International Journal of Information Management, among others. We hope you enjoy this episode.

Dr. Ellis, first of all, thanks for taking some time to join us today on the Cyber Compliance and Beyond podcast. Could you just help us understand what it is you do, and in particular, how you prepare folks to go out and not only support their businesses but also keep cybersecurity top of mind?

Selwyn Ellis:

Yeah. I’ve been at Louisiana Tech since 1999. And since 2009 we’ve had a program in information assurance that is certified by the NSA. And what’s neat about our program is we are very much slanted toward business and cybersecurity. What we try to do is we try to educate our students on the importance of, obviously the cybersecurity aspect, but how it fits into the needs of the business and business efficiency, and protection for the business from the cyber world.

Cole French:

Are there any specific ways or methods you’ve found that are helpful in bringing those two things together? One of the things we run into a lot as compliance practitioners, because I know you’re coming at it more from an academic perspective on the practitioner side. There is this divide between the business side of it, you business leaders who are looking at the bottom line and strategy, and those type of things. And then the security teams over here who are looking at cybersecurity threats. And really, a lot of times, are just seen as a cost. What are some specific things you guys are doing to try to bridge those gaps in the academic space before, obviously, some of these folks go out into the business world?

Selwyn Ellis:

Well, the real world gets their eyes opened, so to speak, when they see these cyber attacks happening. When they read about the big ones, which we all see on the news, but when it happens to them. Give you a couple of personal personal… Well, one personal example, A very close friend of mine, over the holidays, his company, a pretty large oil and gas company, got ransomware. I’ve known him for several years. He’s never taught cybersecurity to me in my life, but all of a sudden he wanted to know all about it.

Through the boardrooms, through the lunches they have, through connections they have, they hear about cybersecurity and they think, “Oh, it’s just out there.” But when it happens to them, it really opens their eyes. What I taught him about, and what we try to teach our students to go to their businesses, is to make sure that you do keep your employees trained, educated, aware of different types of attempts for the bad guys, so to speak, to get. In his case, it was a leaked password from one of his users, and they got access to a network. And there you go.

Cole French:

Is he working on any follow-up? You mentioned the awareness and training part of it, but is he changing anything?

Selwyn Ellis:

He does his IT management as a service, and he’s looking at different vendors now. He thinks there was some negligence there. But obviously all of his employees know, especially his true operational users, people who access the network every day, they have been trained a lot. He’s gone through various protocols with them. But the big one he’s doing is making sure that his service provider is more aware. I think in his case he was just so dependent on them and didn’t look at it a lot. And just because you have a service provider doesn’t mean that they’re taking care of everything. So he’s having to do a little… There’s a lot of trust there, but he’s having to hold them accountable, let them be more accountable to him.

Cole French:

That’s something we talk a lot about is the supply chain. I think that has become a much more prevalent topic of conversation within the compliance space in general. But I think within… Well, I guess I would say within organizations in general, and within the compliance space in particular, exactly what you said. I think when we conduct risk analysis, which I know we’re going to talk about in just a bit, we really have to look at it isn’t just, are my controls operating effectively within my own organization? It’s much broader. Every organization relies on some type of service provider, and I think we have a tendency to think of service providers in an IT context. But the reality is that there’s been plenty of stories out there of the HVAC guy got access to the network because he needed to access one thing on an HVAC panel. And that account gets compromised, and it wasn’t provisioned properly, and now you have a huge problem. And that’s not even an IT person.

Selwyn Ellis:

Well, and I think the way I present it to students is that when you get a service provider, when you outsource any function, you shift that risk, but you don’t totally eliminate that risk. Just because somebody else is bearing part of that risk for you, that doesn’t give you the right to say, “Oh, that’s taken care of.” I think that’s the way a lot of business leaders tend to view it until they are attacked.

Cole French:

Are you guys doing anything to help folks prepare from a supply chain perspective specifically?

Selwyn Ellis:

I’m going to let Jake hit that one. Jake?

Jake Lee:

Yeah. We talk about importance of supply chain in terms of the information assurance in the classroom. I think the most important thing for students to be ready to go real world explaining or their understanding why information security or information assurance is important. This is how I explain them. Every class I said profit is important, or goal of the company. In order to increase the profit, we need to use the formula, profit is equal to revenue minus expenses.

If security incident happen, that impacts on the expenses, which means cost. If we have high cost, our profit is going to be lower. By using this information or by using this formula, I normally tell my students to understand why information security is important. If they do not comply with the policy and regulation or that, it’s going to provide a bad impact to your company. By understanding that importance of information security, which means by having the security concern before they graduate from the college. After they get a job in the real world they follow the policy, the information security policy, and they will be beneficial to the company ultimately. That’s how I educate my students.

Cole French:

And Jake, thank you for joining, us by the way. And as you talk about risk assessment, this is a common misunderstood concept in compliance. In that a lot of times when we’re about… There’s controls. That in CMMC, FedRAMP, these different compliance frameworks will have controls around conducting risk assessments. And what often happens is organizations conflate a security assessment. Which would be either internally having an internal audit team, or bringing in a third party advisor to conduct a security control assessment. How am I doing from a compliance standpoint, for whatever framework it is that I’m adhering to? That’s a security assessment, or security control assessment. And a lot of times folks think, “Oh, that’s my risk assessment.”

Now, it certainly can be a part of a risk assessment. A security control assessment can be a component of how you gauge and assess risk in your organization. But as Jake, you just described, there’s a lot more to risk than just, do I have my security controls implemented? When it comes to conducting a full scale risk analysis, what’s the procedure? You just mentioned the formula and how you calculate that. But if you could take it a step deeper and go into, what are the considerations, what are the things that folks within the business or in the boardroom, so to speak, need to be most concerned with as they determine how could this impact our business and making the appropriate risk mitigations?

Jake Lee:

That’s a really great question, and that’s very important. I emphasize student need to understand what is risk, what is threat, what is vulnerability, what is asset, what is potential loss? They can expect it first. And then they need to understand why this risk assessment is important. What’s the purpose of this risk assessment? Without having knowledge why we are performing this risk assessment, there is no way we can have a perfect… You cannot be perfect anyway. We may not able to have usable or appropriate risk assessment report, or risk analysis report. Most important thing is having understanding why this risk assessment is needed. And what threats, vulnerabilities, asset, and potential loss we are expecting.

We need to know those kind of things first, and then follow the process for the risk assessment, like applying appropriate risk assessment approaches and performing risk assessment and analyzing threat vulnerability and its exploits, and figuring out risk mitigations and all that. Long story short, most important thing before we start risk analysis is understanding our current situations.

Selwyn Ellis:

I think that’s one reason it’s imperative that you have multiple parties, multiple employees, and multiple levels represented in a risk assessment exercise is because Jake mentioned vulnerabilities, potential risk, potential threats. The level of vulnerability is probably perceived differently by different levels in the organization, especially their technical competence. One thing about vulnerabilities too, you look at how severe that threat could be to you. And to a, let’s say a CEO. I sit on the board of a couple companies, but to my CEO, his threat… He thinks we may be vulnerable, but the threat is not really that high. His IT person looks at it and goes, “No, no, no, we’re extremely vulnerable. We better take these mitigating steps.” The perspective of the person is extremely important when you’re doing a risk analysis also.

Cole French:

And I think that ties in with Jake’s point about understanding and articulating, what’s the reason for this risk assessment? And it’s essentially you want to have buy-in on doing a risk assessment. And I think the more voices you have, the better buy-in you’ll get. It may be more difficult to convince everybody or to bring everybody onboard, but the more voices you have, the more representation you have, I think the better outcome.

Selwyn Ellis:

Well, and as a business point too, there’s probably close to an equilibrium point where you’re willing to accept certain risk. And you’ve got to decide, like you said, the different perspectives, how much of your attention you want to pay to that, how many resources you want to throw toward that risk to mitigate it.

Jake Lee:

And as I just mentioned, no risk analysis can be perfect, that’s why we need to have a regularly performed risk assessment. That’s why even though having multiple parties for the risk assessment can be difficult, but ultimately it will be beneficial for the company.

Cole French:

Yeah. One of the challenges with risk assessments, frankly, like I mentioned earlier, I think there is a little bit of confusion around them. But a true risk assessment, and we’re peeling back the layers of the onion on this, but a true risk assessment is an undertaking. It takes a lot of coordination. It takes work to bring people onboard. You really got to think about a lot of things. And I think it’s easy for us to spend all of our days in the minutia of the day-to-day operations. And a risk assessment is more of a strategic exercise, and so it can be hard to bring everybody in on it and then to get everybody’s mindset in the right place to properly evaluate all of this.

And Dr. Lee, Jake, I wanted to ask you, do you have a particular risk assessment approach or risk analysis approach that you recommend? Where should an organization start with this type of effort?

Jake Lee:

As I mentioned, I think defining the current situation of your company is the most important thing, knowing what’s risk, what is your threats, what are vulnerabilities you can expect? And what are your assets to be protected? What can be potential loss? Risk is equal to… I’m talking about the formula again. Risk is equal to threat multiply vulnerability, multiply assets. As everybody knows, threat is always there, it cannot be eliminated. The best way we can handle this risk is minimizing or mitigating vulnerabilities. Action can be taken to reduce potential threat to occur. Action can be taken to reduce the impact of threat by managing vulnerabilities. Without knowing what vulnerabilities what we have now, it is possible to managing risk. I think knowing our current situation is the most important things too at the beginning of the risk analysis process.

Cole French:

Do you find… Go ahead.

Selwyn Ellis:

Well, I was going to say the NSA does map our courses back to, we use a lot of the NIST frameworks that are put out there. We have to map our curriculum to that particular framework when we teach any subject.

Cole French:

Is it a specific framework, or is it NIST frameworks in general?

Selwyn Ellis:

It’s NIST in general. Like I say, our coursework has to line up with what they’re… We have to map everything back to their guidelines. And if you think about it, they just basically, as most framework’s core is going to be identify, protect, detect, respond, and then recover. And so that’s what we base our curriculum on.

Jake Lee:

Yeah, there are many frameworks, standardization or standard guidelines, but we are more focusing on NIST. But in my class I mention about other guidelines like COVID and all that. But we are more focusing on NIST.

Cole French:

What challenges do you see, both in the classroom, and if you’ve seen this in the real world as well? When it comes to threats, you mentioned identifying the threats, what are some challenges that you see with folks identifying threats? Do you feel like that’s an easy thing for people to identify, or do you feel like it’s easy to miss things when it comes to threats? Because as a cybersecurity person, practitioner, when I think threats, I think cybersecurity type things you could say first and foremost. But there’s also other types of threats that aren’t necessarily in the cybersecurity realm. Do you find folks have challenges with just articulating the threats?

Jake Lee:

That’s a really good question again. That depends on the person, or it depends on the student. If students can spend a lot of time to identify threat, they may be able to find a lot of threats. But if students want to use or find or spend a little bit of time to find threat or define threat, find threat for him or her, they will only find a small number of threats. What I want to tell you is it can be challenging for some people, or it may not be challenging for some other students.

Selwyn Ellis:

You tell me, do they recognize? Well, I think it’s becoming harder to recognize authentic threats because of AI. And by the way, NSA has a new program on the use of AI and cybersecurity. But there’s so many artificial intelligence generated phishing attempts and tactics that make threats harder to recognize, at least specific threats harder to recognize. And on top of that, probably your biggest threat is the person working in the office by you. And you certainly don’t look at them as a threat, and you don’t recognize when they’re doing something that is a true threat to say your server to your information technology. I think threats are often overlooked.

Cole French:

And the one you just touched on at the end there is essentially insider threat, which I think has gotten more play and more publicity in recent years, but is still probably the most difficult to detect. If they’re folks we work with every day, it can be really difficult to spot behavior that is slightly suspicious, but may have really nefarious consequences behind the scenes.

Selwyn Ellis:

I’ll hit one that would take your compliance people, but just basic workarounds. How we all have ways that we, and I don’t want to say break the law, but we break the cybersecurity policies in our office in some way by having various workarounds. We’ve done a lot of research, some large companies or larger companies around this area. And I remember going to one company working on a project like this, and they were adamant that we never share passwords, we never do anything that would in any way infringe on the security of our systems. And then we started talking deeper and they said, “Well…” We said, “What happens if so-and-so is not here for work and they need to do this?” “Oh, they just give us a password.” But yet they’re adamant that they don’t do anything that would threaten security. Well, giving a password away is about as big a threat as you can get.

Jake Lee:

Yeah. That’s why complying with the security policy is really, really important.

Cole French:

And thinking about it, I think that example that you mentioned is… Yeah, workarounds. That’s the thing with workarounds is we don’t really think about them now. I think it’s understanding the compliance, but also stopping to think, wait, am I creating some risk by implementing some sort of workaround? And you’re exactly right. And in the compliance space, we see stuff like that all the time. And there are always going to be workarounds and a risk acceptance. I know we’ve talked about risk mitigation, but there is also the concept of risk acceptance, and having a strong risk acceptance procedure and policy for workarounds. Because workarounds are…

Obviously, giving a password away is not advisable. Or sharing a password, I should say. However, there are other security exceptions that are necessary. I can think an organization may block particular apps at the firewall. However, certain users may work with certain customers who use those apps, and so you need an exception for that. And that’s fine, but it should be documented. That exception should be run through some evaluation process. And then most importantly, that evaluation should be reevaluated. Things we’ve seen in organizations is there’s a good risk acceptance policy and procedure, however, it’s missing one key component. And that is, we have risk acceptances that are still in place from five years ago because nobody’s reviewed the ones we implemented.

If a user is given an exception to access a particular application, within some frequency that risk exception should be reviewed to determine, is that even still necessary? The work with that particular customer that required that exception may no longer be in place or may no longer be needed, so at that point, we should remove that exception. I think that’s a risk. The risk acceptance itself can create a further risk because we don’t go in and actually review these and remove them when they’re no longer necessary.

Selwyn Ellis:

That’s a really good point.

Jake Lee:

That’s because of the needs difference by department. Like IT department versus marketing department, their needs maybe should be different. This can be explained as a convenience versus a security relationship. I totally agree that risk acceptance policy need to be reviewed every and very often, because needs changes. But having a really good security policy in document is really, really important, because everybody needs to follow that policy for the company.

Cole French:

And I think too, this is one of those areas, we talk about this a lot on the podcast, but automation. I think this is one area where organizations can really leverage automation. Going back to the example that I mentioned, we poke a hole in the firewall for this particular application, for this particular user. And modern firewalls, you can time bound those exceptions. You can say, this exception is good for 90 days. And then after 90 days that exception will go away. If that user needs it still, then they got to go through the risk acceptance and procedure all over again.

Yeah, we always run into the inconvenience, so to speak, with security. But if you have a good process that runs quickly and efficiently, then it’s a minor interruption to a user to have to go through that process again. That’s one way you can really leverage automation. I always caution against thinking automation is the be all end all, because sometimes automation causes us to fall asleep. And then the automation doesn’t run or work properly, and then we end up thinking something’s taken care of, in reality it wasn’t. But I think this is a case where automation can be very helpful.

Selwyn Ellis:

I like your point about the timing and letting those exceptions expire after a certain time period. Because I think of things that I’ve changed for security purposes on my machine, and then I just forgot to change them back. So having a timeframe like that, that’s a great task… Something to implement all you in the security features that you have at your office. That’s a good one.

Cole French:

And I think security is always balancing the level of inconvenience. And I guess this gets to your risk… This is part of the risk assessment too. How much inconvenience and degradation, if you will, of the business operation am I willing to tolerate? And I think it’s, on this case, a user has to go through the process again and get that risk exception re-enabled. Or the alternative is, we don’t use automation at all and now people have to sit there and review these whenever they’re due manually, which is certainly taking away time that they would be spending doing other things. It’s like, which one? Where do you get the most bang for your buck, essentially? And I think, to some degree or another, automation helps us with that by reducing the manual-ness of someone going in and actually looking at, oh, is this risk exception still needed? No, it’s expired. All right, we’re going to turn that off. I think it’s a great opportunity to really evaluate what makes the most sense and maintain security.

Selwyn Ellis:

I agree.

Cole French:

All right, so we talked about threats. Once we identify the threats, Jake, remind me again. The next step after we identify the threats in terms of performing a risk analysis would be?

Jake Lee:

Altogether, threat, vulnerability, assets, and potential loss.

Cole French:

When it comes to vulnerabilities, when we’re talking about risk analysis, some people might think threat, vulnerability. What would you say is the difference between a threat and a vulnerability?

Jake Lee:

The threat cannot be eliminated. Threat exist always. And there is nothing much we can do for the threat. With vulnerability, we can control that by applying some controls. I think that’s the main difference between threat and vulnerability in terms of risk analysis.

Selwyn Ellis:

A prime example, last night we had flash flood warnings all over north Louisiana where we are. The threat was there, we couldn’t do anything about it. But the neat thing is, I’m not vulnerable because my neighborhood is not close to any water that overflows. That’s a very low level and practical example. But as you say, threats can’t be eliminated, they’re there. Vulnerabilities, you can at least have some measures that you can take to change how vulnerable you are to those threats.

Cole French:

How do you help folks identify vulnerabilities? Now, that’s a very good distinction between those two. A threat like what you just mentioned, the flood is the threat, but the vulnerability of it is dependent on where you are. How do you help organizations identify vulnerabilities?

Selwyn Ellis:

Well, in the cybersecurity world the way you change your level of vulnerability obviously is have those controls in place, and those policies and procedures in place, and you hope that your employees abide by them. Specifically, password policies. Or make sure any firewalls are up-to-date, make sure that you’re at least paying attention to the… The vulnerabilities or the threats are basically the same for everybody. You just have to make your people aware of those vulnerabilities and try to mitigate what you can.

Jake Lee:

Yeah, that’s why students need to be familiar with the CVE, common vulnerability and exposures. There is a website the knowing vulnerabilities are listed. Based on that information, people can know what vulnerabilities exist. But if this is not a known vulnerability, it’s called a zero-day vulnerability. After it is disclosed this is a vulnerability, then it’s not going to be zero day anymore. It will be listed in the… What is it? CVE website. I always suggest my students to check CVE website.

Cole French:

And I would say too, use vulnerability scanning tools that can enumerate vulnerabilities, and then those enumerated vulnerabilities will be mapped back to the CVE database. When you’re doing a risk analysis… Risk analysis, I think of it as a high level thing. Vulnerabilities can be articulated in many different ways. Like you said, the threats are more static, I guess. Whereas the vulnerabilities are more specific to the context, to the type of asset we’re talking about. When you’re conducting a risk analysis, how do you quantify vulnerabilities? I may be vulnerable because I don’t have X, Y, and Z in place, but also I have a thousand machines. How do you quantify the vulnerabilities when doing a risk analysis?

Jake Lee:

There are two ways of performing risk analysis, one is quantitative and the other one is qualitative. You are asking me about quantitative methods. As you know, we can draw risk metrics by using likelihood first, and the threats. We are using percentage normally for the vulnerability, which means potential likelihood.

Cole French:

You mentioned the CVE and vulnerabilities within systems. Do you use those in a quantitative risk analysis? Do you use inputs from vulnerability scanning tools or CVE databases?

Jake Lee:

Yes, sometimes.

Cole French:

And how do you go about that?

Jake Lee:

The program I ask my student to use comes with a percentage. I just directly ask them to use the percentage number.

Cole French:

Essentially, is that specific to a particular system or set of systems, or is it just theoretical?

Jake Lee:

Theoretical and sometimes particular process, not the entire system. Just the process. For instance, again, I’m using the same example that Selwyn used, the vulnerability of flooding in his housing area. Maybe there is a vulnerability of 10% or 20%, something like that. I’m using that number to perform risk analysis.

Selwyn Ellis:

We do a lot of analytics work, and the thing about probabilities assigned to vulnerabilities, sometimes it can make you very complacent thinking you’re not very likely to experience something. And it can give you a false sense of security. I had a economics professor when I was in college that said, “The probability of anything’s 50/50, it happens or it doesn’t.” Which is not quite true. But you understand the point of me saying that is a low likelihood or a low probability of some vulnerability that still doesn’t forgive you for not paying attention to it. It just tells you to pay less attention to something than another potential vulnerability.

Cole French:

That’s a great point. And having worked in the past in vulnerability management and helping organizations identify and remediate vulnerabilities, that’s one of the biggest challenges with vulnerabilities is the piece around… I can look at it and go, oh, that’s a critical, I should patch that right away. That’s true. We do always say patch in order of severity. But also, there’s another layer you can go down into of, okay, what are the systems that I’m talking about? And just a rudimentary example is public facing versus internal systems.

On a public facing system, I need to be hitting every vulnerability that exists on systems that are public facing just because they can be accessed by the public. But systems that are internal, and even I can look at the internal nature of those systems. If they’re highly restricted, even on an internal basis, I can patch them a little bit differently or treat those vulnerabilities a little bit differently than I would on my public facing system. I think, and Jake, I’m sure you probably say this too, the asset component of the risk analysis is determining, what is the significance of the asset in play? Is that correct?

Jake Lee:

Yeah, sure. Yeah.

Cole French:

Just to sum up the risk analysis, we’ve got to identify the threats, identify the vulnerabilities, and then identify the assets. And by identify the assets, obviously, yeah, I got a list of all my assets. But you also need to understand, what’s the criticality of those assets? How do they impact the business? If something were to happen to one of those assets, what would the impact be? And that’s probably going off into more contingency planning, disaster recovery type stuff. But that even also, if we expand the risk assessment even broader, that’s stuff we’re getting into. That isn’t necessarily something that is involved in every compliance framework that’s out there, but in a lot of them it is. You got to get the whole picture, you got to be conducting a risk assessment, contingency planning, disaster recovery, backup and restoration, all of that stuff. I think all those things complement each other, and the inputs from one affect the other in some way, shape, or form.

Selwyn Ellis:

This just shows the complexity of a true risk analysis. Because as you say, the criticality plays a major role. And then you start talking about combining probabilities and then, like you say, a very critical system somewhere, it can change the way another less critical situation is just because of the criticality of the nature it is. And I could give examples, but you understand me. You’ve got some server somewhere that does life or death to your business. Hey, that’s critical. You can’t minimize it.

Cole French:

Exactly.

Selwyn Ellis:

And as I say, the probability world, that’s truly my expertise is quantitative methods and analytics. And I guess people get confused sometime about when you see one thing being critical and something else and you start multiplying probabilities time to other probabilities and how they affect each other. Which means these reports can be very, very complex in nature. And understanding them can be complex.

Cole French:

Yeah, I can definitely see how that would be the case. And you mentioned the quantitative, Jake, you had mentioned qualitative. Are qualitative risk assessments a little… It’s interesting, I’m more of a quantitative thinker. I tend to think numbers and probabilities and stuff like that help me sift through information. Help me understand how qualitative assessments differ from quantitative, other than I know it’s you’re not maybe assigning numbers or probabilities. But how is the qualitative risk assessment different?

Jake Lee:

Qualitative is a little bit more subjective than the quantitative. It’s very, vulnerability sometimes very relative by asset. And by using subjective opinion we can perform the qualitative analysis. But my suggestion to my student, using both analysis together, quantitative as well as qualitative. That can make their risk analysis report is more impactful. They can make better report for the risk analysis by using both quantitative and qualitative.

Cole French:

Do you recommend one before the other?

Jake Lee:

Not really, but I always suggest use both quantitative and qualitative.

Cole French:

I think that makes sense. And in my mind right now as I’m thinking about, it seems to me doing a qualitative approach first would seem like it would help get the process going, help get some things identified. And then you move on from the qualitative, taking what you identified in the qualitative and applying more of a quantitative approach. Would that be something you would advise?

Jake Lee:

Yes. And/or qualitative first and then quantitative later. The order doesn’t matter. If student, or if report contains both analysis, I think it can provide more strong information for the report.

Selwyn Ellis:

Just a more comprehensive look at the situation.

Jake Lee:

Yes, that’s right. Yeah, yeah.

Cole French:

Absolutely. Qualitative and quantitative risk assessment. I really appreciate you guys, Dr. Ellis and Dr. Lee, for coming on today and sharing the academic side of this topic that is particularly challenging, or that we’re seeing is particularly challenging. And I think the academic perspective is one that we can reach back to. Sometimes when we get out in the real world we’re dealing with real world problems, and some of those academic things we learned in our younger years, so to speak, we need to revisit those and go back to those. I’m grateful you guys were able to come on today and share this unique academic perspective with us on a particularly challenging topic.

Selwyn Ellis:

Yes, thanks for having us.

Jake Lee:

Thank you very much.

Selwyn Ellis:

It’s nice to link back to the real world. It is been a while since I’ve been back in the industry, even though I served on some boards, as I mentioned earlier. But it’s nice to connect with industry people. Thanks for inviting us.

Cole French:

Thank you for joining us on the Cyber Compliance and Beyond podcast. We want to hear from you. What unanswered questions would you like us to tackle? Is there a topic you’d like us to discuss, or you just have some feedback for us? Let us know on LinkedIn and Twitter at Kratos Defense or by email at ccbeyond@kratosdefense.com. We hope you’ll join us again for our next episode. And until then, keep building security into the fabric of what you do.