What is GRC in cybersecurity?

Governance, risk, and compliance, the GRC

component of information security, gets a

bad rap in the cybersecurity game.

This week, I'm going to throw some love

toward GRC and tell you what you need

to know about it

to be successful. Coming up.

[Music]

Hey everybody. Welcome to Simply Cyber,

the YouTube channel designed to help you

make

or take a cybersecurity career further,

faster. I'm your host, Gerald Auger, and

I'd like to give a special shoutout to

our sponsor, Coastal Information Security

Group,

for being our sponsor. Really

appreciate that. Also in the background, a

little shoutout to

HackerSploit, another YouTube content

creator and excellent, excellent resource

on the internet.

More on the Bug Bounty and Pen Testing

side, but check out his link below in

the show notes.

Just he does amazing work.

And be sure to stay tuned to the end,

where I have my "One Cool Thing" segment,

where I share something completely,

you know, what I think is cool and,

that I wanted you to know about.

But let's get into GRC. So GRC, or

governance, risk, and compliance,

is a critical piece of any mature

information security program. So a lot of

times, the red team, the blue team,

hands-on hard skills, technical scanners,

you know, hacking, passing the hash, like,

popping shells, all that stuff--

that's all sexy and cool, and it's

definitely an important part of

information security.

However, governance, risk, and compliance

has its place, and it's equally important

in some regards. Now, I will preface it by

saying

smaller businesses and smaller programs

are not going to typically have a GRC

component. They will have some compliance

requirements in some situations,

whether or not they're actually adhering

to them or doing anything;

due diligence and due care to meet them, is a

separate issue. GRC

is going to be for more of your medium-sized

organizations and definitely,

definitely large enterprise

organizations. So think Fortune 500

companies. There's absolutely zero

question

that they have a GRC component to their

information security program,

and there are jobs there. So that's why

it's so important

to A) understand if you want to go into

that particular

field of information security, but B)

have the context of what that function

does,

even if you are a blue team or a SOC

analyst or something like that.

It's important to understand that. So,

what exactly

is GRC? So GRC is these three things,

right? Governance, risk, and compliance.

Governance is basically how the

organization itself governs the way

things are done.

And, you know, what does that kind of look

like, right? So that looks like:

Can anyone in the organization

install

any software they want on any system?

Probably not,

but there are rules around that, right? Can

you go can to a p***

website on your lunch break? Can you

bring in an Xbox and plug it into the

network and have a LAN party

if people still do that? Maybe, maybe

not. I don't know.

Those are acceptable use policies, and

all of that is how

the organization governs both its end

users

and its IT assets, and

itself really--like, what is acceptable

behavior? What is the culture of the

organization?

And that's what governance is. It's not a

tool,

although tools can help you implement it

effectively. It's not a skill.

There's no GitHub repo for governance.

It's an

organizational cultural element of how

it's implemented. Okay? So it's very

difficult to wrap your head around

until you get it, and then

it makes sense, right?

Next is compliance. Compliance is

complying with whatever federal

regulations,

industry regulations, or whatever

regulations and requirements you have to.

So, quick

big ones, for example, PCI--the

Payment Card Industry.

They have their own compliance standard

called PCI.

So if you work at a business or an

organization that takes credit cards,

or you take credit cards, you have to

comply

with PCI. You don't have to, but if they

find out that you're not compliant,

they, the credit card companies will

restrict you

from being able to use credit cards. So

think about your food truck,

right? And you're using credit cards, but

you're not complying with the PCI standard.

They could take that away, and now you're

a cash-only food truck. I don't know. It's

2020.

Where I am, I don't carry cash. So,

you're incentivized to comply with

that standard because you want to be

able to take credit cards. Another one

is HIPAA, right? If you work in healthcare,

you've probably heard of it:

HIPPA compliance, and basically

compliance standards, are

a minimum set of security controls and/or

privacy controls or whatever. It's

some minimum set of standards

that an organization must implement

to be compliant with the standard, and

then there's a whole host of, like,

testing that you've implemented and

auditing and passing an audit, and having

an action plan for closing out

findings where there's gaps, you know, etc.

So that is what the compliance piece of

it is. Now,

compliance and governance kind of work

hand in hand because if you have certain

things that you have to comply with, like

I said with PCI--like, all credit

card data needs to be encrypted--

okay. So then you can have some policy

that states,

"All credit card data must be

encrypted" or "All data at rest must be

encrypted" or whatever.

So now you, like, you put the policy in

place, but if people are like, "Oh

f-off, I'm not going to follow

that. I'm like sysadmin. I don't have

time for encryption and stuff," or

"I'm the data analytics

person on our team, and

it's like inconvenient for it to be

encrypted because I have to go decrypt

it every time

I want to train an algorithm or

something like that." Well,

now it becomes governance--tone at the

top, which is

absolutely critical to any

organization's success. Tone meaning

the leadership, who's defining what is

acceptable behavior in the organization.

Standing behind what the

governance model of those policies and

procedures--are

you following them? And then,

ultimately, if you aren't, what they do

about it? Right? Sanctions,

you know, terminations, etc.

That's the only way it really works. Okay?

Third is risk. Now, spoiler alert if

this is new to

you, but you cannot be 100% secure,

ever. I don't care how good you are--

national security systems,

submarines with missiles on them, like

there are

vulnerabilities. Whether it's human

vulnerabilities, attacking the human

social engineering,

technical vulnerabilities

through exploitation,

not patching, or physical security--you can

walk in and plug a USB drive in. Whatever

it is,

there is going to be

some risk, right? But what is that

risk? How do you qualify that?

How do you quantify that? And that's what

this piece of the risk

in GRC is. And it's actually a fairly

large one

and one that gets a lot more attention

than the other two.

So, risk is either assessed either

qualitatively or quantitatively. That means

you

say, like, "We have some risk. Our

risk is

moderate. Our risk is low." It's some

qualified, subjective

value that people kind of agree on,

but it's difficult to

measure.

Quantifiable is measurable, where you say,

you know,

"Our risk was, of whatever is at 34%

of risk, and we're going to implement

these three controls.

And that's going to reduce our risk to

17%. And organizationally,

at the governance level, we're

comfortable with 20%

risk." So quantifiable is a little bit

harder. You need to be, like, a much more

mature organization in order to have the

metrics to support what that

quantification is.

Qualitative, you'll see a lot more often.

A couple resources that I want to share

with you: Again, there aren't really

tools necessarily within the GRC space, but

NIST has some special publications

that you should be aware of. 800-39,

that is kind of showing you how to

implement an organizational kind of

risk management framework. It's not 837,

which is the risk management framework--

you can check that as well--but 839 talks

about risk at the organizational level,

risk at the system level, which is what

most people think of when they think of,

like, an unpatched system, and stuff like

that.

As you do audits and things like that,

like, you can, you have to do an audit,

right? So

let's say you're going to put in some

controls, then you have to test the

effectiveness of them because, a) they

might be configured wrong, b)

you might have end users that are

intentionally circumventing them for

whatever reason.

Once you assess them, you get some score,

and then you find out where the

weaknesses are, and then you put an

action plan in place to

remediate those. And then you have to

report that up to leadership or the

board or whoever,

on where you are today, where you are

tomorrow, and what your plan is and how

you implement.

And then all of these things come with

financial

obligations, oftentimes, where you need to

purchase a tool or purchase some access

to some

configuration baselines, for example, or

something like that, or some knowledge,

or hire people in order to

implement or maintain appliances or get

contractors to do it.

So GRC is a big thing.

It takes time. Again, it's more angled for

medium to larger organizations, although

small ones do need to really worry about

the compliance one.

But from a governance and risk

perspective, small organizations are

typically,

and really even compliance, they're just

flying by the seat of their pants.

They're assuming that they're compliant

with whatever standard, or they're

unaware of the standard,

and they have a

basically naive idea of what their

current risk posture is and what they're

willing to accept. And it's really naive

because they're

unaware. And I'll just point out, like,

you know, whatever, shameless plug: My

entire dissertation for my PhD

was focused on this naivety of what

their risk tolerance was and what

actually led to why that risk existed.

So, if you're interested in digging into

a 200-page book I wrote on it,

you can dig in there. So, again,

I just wanted to spend a minute. This is

important, right? So the blue team is

defending. The

red team is attacking. But like, what are,

like,

where should they focus their efforts?

They can't defend everything, right? So,

governance,

compliance, and really what your

risk profile is

defines where they should spend their

efforts or how you should spend your

money

on what controls and tools. Just buying

the coolest new tool that's at Black Hat

or like the vendor that has the biggest

booth--yeah, you can do that. But like,

is it quantifiably a

material improvement to your risk

posture, or is it literally doing you

bought a PA firewall,

now you're going to buy a Fortinet firewall,

and you already got them? So, it didn't

actually improve your security posture,

it just hit your budget,

right? So GRC, it gets complicated,

but that's basically it. There are

some tools that help you manage and

communicate out to organizations what

your policies are,

but, you know, oh, another, like, quick

pro tip:

Policies, like, don't write 400 policies

for the sake of

compliance, right? You should write a

minimum of a couple policies that are

important to your organization

and communicate them throughout

the organization and have governance

and senior leadership buy-in, or else

you're never going to succeed

with that. Okay. If you've got any

questions about GRC,

put them in the comments below. I'll

answer them. I love engaging with

you all,

and I'm happy to have spent some time

throwing some,

throwing some love and showering

the GRC to the side of the house

instead of just new tools and cool

hacks and stuff like that. So now it's

time for our "One Cool Thing."

My one cool thing is I can't remember

the name of it right now, but it's

a Netflix show I watched last night,

and it's actually really

interesting. I'll put it right here. I

forgot the title.

But it's basically about how social

media companies have developed,

how, like, basically, how engineers have

engineered user interfaces to

promote interaction and time

spent on the platform.

There is, like, a whole kind of

dramatic use case that they splice

in periodically about, like, the abuse of

how it could affect a family. It's a

dramatization, and I didn't care for that

part.

But they're interviewing, like, the

president of

Uber, the CEO of Pinterest, or

former president of Pinterest,

lead engineers at Google, and interface

engineers at Twitter. Like,

high-end, really smart, you know, Stanford

graduate-type people

who are talking about the humane

elements of technology and how,

you know,

like, it's interesting.

I'll put it this way: It's worth checking

out. I personally

have spent a lot of time on my phone. You

know, it's the first thing I look at when

I wake up. I typically check it when I go

to bed. Like,

I went in right after I was watching

this or while I was watching it, and

disabled notifications on just about

everything that I don't really care

about. I left my,

you know, messages and my email because

that's how people normally communicate

with me. But

just all the superfluous f****** app that want

to send you notifications,

steal your attention, and disrupt your

focus on whatever it is. I

disabled all those, and I felt better

about it. So, great little documentary.

Recommend checking it out.

Okay. Thanks, everybody. Love

engaging with you, love

doing the show, and until next week,

stay secure.

[Music].