Trillions of lines of code in billions of devices, with ubiquitous connectivity across the globe.

The Magnificent Seven contributed 58% fo the S&P 500’s total return in 2023. Historically, the top 10 stocks in the S&P500 contribute 14% of the index’s total return, showing the current over-concentration

GRC is an acronym that stands for Governance, Risk, and Compliance. Each of these are kind of independent of each other and we'll break down each of them. But they basically ensure that an organization has a methodical and intelligent approach to driving cyber risk reduction.

Even if you had infinite money - here's a blank check, go buck wild, you got a genie with three wishes and the first wish you wish for is infinite money, good for you - you know what you can't do?

You can't buy all the tools. You can't train all the staff. You can't keep staff who know what they're doing there because they might go to another place. So infinite money doesn't equal infinite security.

But in reality, we don't have infinite money. We don't have infinite resources or infinite time. So what we need to do is figure out where we need to spend our money, what we need to prioritize first, and who's going to do the work and how they're going to do it. This is what GRC basically is - looking at and thinking of.

Also, bonus tip: there's actually academic research that shows there's diminishing returns the more money you put in. I.E. if I give you a million dollars, you can get your InfoSec program to pretty good. If I gave you another million dollars, you wouldn't double the effectiveness of your cyber program. It would only be like a percentage of that. So there's a logarithmic curve.

Governance is basically what are the rules of the business and what is the attitude of the business? What is normal at this business? And then having leadership be like, "No, this is important."

Governance can also include frameworks. I'm a huge fan of the NIST Cybersecurity Framework and CIS Top 18.

Frameworks are great and it allows you a repeatable, mature process in order to grow into a mature InfoSec program and make sure that you're hitting comprehensively all the elements of a cyber program. Making sure that you're looking at people, process, technology - not just saying "Oh, we're taking backups and we've got multi-factor, we're good to go." Yeah, okay, but are you doing configuration management? Are you doing vulnerability management? Are you regularly pen testing your environment? Are you doing risk assessments? Who's allowed to access what? Do you revoke credentials if they get compromised? Who's allowed to do that? A million things!

And then finally, compliance. This is like your on-ramp to GRC. Compliance is straightforward. There's a list of documented requirements, whether it's PCI (Payment Card Industry), or it is HIPAA (the Health Insurance Portability and Accountability Act). I don't want to say compliance is easy, but compliance is easy to understand. Here's a bunch of things: are you doing them? Yes or no. This is where a lot of GRC people actually start in their career because you audit against the compliance standard.

Let's talk about the next one: risk. What is risk? Again, like I said before, you can't secure all the things. You will always, always, always have residual risk. I don't care what you're doing, what industry, what size org - you will always have residual risk. So it's managing how much of that residual risk exists with respect to funding or budget, manpower or person power, and just resources like time and stuff.

"Oh cool, Security Onion, what a great tool! Let's roll it out." Okay, well what are you going to put down in order to roll out Security Onion? "Oh, I didn't think about that." And once you roll it out, who's going to manage it, maintain it, care and feed it? I can't tell you - honestly, quick side note - I can't tell you how many abandoned projects I've seen in my career. People get all geeked up like "Oh, let's roll out Security Onion!" And then like a month later, you've got it rolled out and then nobody's using it because nobody's managing it. And then it's like, "Oh, that was a lot of fun."

That's what risk is. We need to understand what is the risk of doing something, what is the risk of not doing something.

Multi-factor authentication - perfect example. In my opinion, should be rolled out everywhere. But maybe some organizations don't want to put it on the executives for whatever reason. They're special snowflakes and they don't want to use multi-factor because it's hard. Well, you could say, "Okay, we are taking on additional risk because

(a) if you reuse passwords or you have crappy passwords, business executives, you're probably going to get your account cracked.

(b) Secondly, without MFA, they're going to walk right through. This could lead to business email compromise, loss of revenue. This could lead to phishing or social engineering of staff and other problems. This could lead to a compromise of reputational harm because you're a publicly traded company and sensitive financial forecasting data gets out because they're in your account."

Is that the kind of risk you want to take on? Maybe you don't say it in that way to the executives - there's a much more polished way to do it. But my point is, this is risk and it's what we GRC folks are responsible for managing, maintaining, and keeping an eye on. Because risk is a very fluid, very dynamic element.

Holler! Let's talk risk assessments. Risk assessments is what it sounds like. There's risk - I just flipped out about that for a minute - and a risk assessment is basically a deliberate method of going through and looking at your, you know, either looking at an application, looking at a system, looking at an overall enterprise, and figuring out where the weaknesses are. And then discovering how bad those weaknesses are, specifically, because some weaknesses aren't such a big deal.

Classic example: you got a Windows XP machine running, which would be disgusting, but it's in a lab environment, air-gapped from the internet. Who cares?

You can see here McSkidy and Grinch are going to basically hand out a third-party questionnaire, which basically gets information solicited from third parties. That information comes in and then based on that information, we're going to assess the risk of their security posture and them holding our data.

Ah, here we go. Be still my heart - the spreadsheet. This is, you know, like if a cowboy has a pistol and a holster on his hip, a GRC professional has a spreadsheet in the holster on the hip. I know there's all sorts of fancy tools, but I'm telling you right now, the spreadsheet - and once you pick up pivot tables, oh my goodness, slow down!

We want to know about data in transit and at rest needs to be encrypted with AES as a requirement. Maybe it's contractually required; maybe it's a business policy that you need AES, which is currently considered secure—AES 256 or higher. What type of AES encryption does your company use for data? Remember, they're holding our sensitive data. The vendor response here is AES 256 for in transit and AES 256 for data at rest. This is right on; I like this one.

If the impact were to get compromised, there would be for sure significant impact of the data. The potential security risk here—we're going to document that this is where the GRC risk assessment piece comes in. It's not very high honestly but data captured and later decrypted—I don't think this is very likely to happen honestly. Quantum computers are where we're at right now, so I'll leave this unlikely but the impact would be high if it were to happen. Let's go ahead and click add risk.

SYMMETRIC KEYS

Produce, control, and distribute symmetric cryptographic keys using [Selection: NIST FIPS- validated; NSA-approved] key management technology and processes.

Discussion: [SP 800-56A], [SP 800-56B], and [SP 800-56C] provide guidance on cryptographic key establishment schemes and key derivation methods.

Alright, so let's go to question two: What kind of access controls do you have to ensure data is accessed only by authorized people? This is very important; access control is huge especially in a modern society where we're doing all sorts of partnering in cloud services and stuff. The vendor here, Violet Wolf, says data can be accessed by all the people on the relevant team. This is decent controls but there may be people on the team who don't really need access—so financial planner, a project manager, contractors that are supporting the team but not directly required to access the data. There is a little bit of a risk here; basically you want ideally only people with a need-to-know to have access—least use or least privilege is the control if you want to look it up in NIST 853.

The risk here is that data is accessed by individuals with access but not with need-to-know resulting in data breach or at least data compromise. Again, if people are getting access to this where they shouldn't—severe impact—this remember GRC and qualitatively assessing the impact and likelihood of a risk is very subjective; it's very fluid. This is why we have discussions about this and you're able to add additional controls to reduce or mitigate down risk levels to acceptable levels.

In this instance we'll say the impact is critical but anytime you make a decision on impact and likelihood you must absolutely be ready to defend it in a meeting because basically what you're saying is we need to invest more into security to reduce the risk to acceptable levels or you're saying we're not going to use this vendor and potentially cost this vendor millions of dollars or cost our business more money because the other vendors are more expensive. Just whenever you're choosing your values it's not just close your eyes and whack-a-mole; it's like literally you have to be able to defend this.

Okay so now let's go to question three: How long do you keep client data after the case is closed? This is a data governance issue—a data retention issue—more than a month is not good; they shouldn't be keeping it longer than they need to.

Data breach—retaining data longer than needed can result in data compromise through a data breach. Honestly you see this all the time with third-party data breaches—literally all the time—and it stinks because typically the business like our business in this case would be the one getting raked through the news and the mud—not the company that held our data. Go look at like the Snowflake breach recently or go look at what CL0P ransomware did with Progress MOVEit software last summer—you know what I mean? The companies that are impacted are not the ones that actually had the data breach.

This is literally the risk we're trying to deal with—significant impact—it would be really bad frankly; it wouldn't jeopardize catastrophic business operations but it would be a pretty high impact. More than a month—I mean you're basically dancing with fire so I'm going to say expected to occur.

Nice job everybody! Learn more about GRC risk management visiting the risk management room at TryHackMe. Let's go ahead and hit complete alright - absolutely crushed it! Hope you enjoyed day nine of Advent of Cyber. I'm Gerry from Simply Cyber, I’ll see you tomorrow.