now, Earlier, when we looked at
the stages of risk identification, we pretty much said you got identify your assets,
got identify your threats, and then your vulnerabilities.
All right, So if we look at our assets, you know, the tricky thing is to realize that assets are much broader than we might immediately think. You know, I immediately think. Okay, I've got hardware, I've got software, got personnel I've got, um, you know, building got material assets.
But also, I have all of these assets that are intangible. You know, like my brand name, our reputation in the industry,
stakeholder satisfaction on other things that are much more difficult to put a dollar value on.
So at this stage, what we're just worried about is naming what our assets are and then getting a broad sense of where they are in the grand scheme of things, right? I'm not asking you for to the penny what company's reputation is worth,
but just knowing that a reputation is one of the company's greatest assets. That's a good place to start when we're in the risk identification stage.
All right, in. So, yes, when we talk about the value of our assets.
What's it worth to us? What's it worth to our competitors?
Are there penalties Air finds? If we're not in compliance with security,
how big an impact does it have on our daily,
um, operations of this assets compromise
reputation costs on and on and on. So there are many things that make up the value of an ***.
Now, once we identify our assets, we have to think about okay, with these assets, what could cost us or calls us harm? And remember,
threats are not always militias.
Natural disasters can be a threat. Accidental deletion from employees.
But we do have to think about malicious threats as well. But the greatest threat comes from inside our organization.
So we might categorize our threats like we might look at them as technical man made natural. Or however you want to categorize them just a za way of grouping your threats in order so that you can have some organization is helpful,
and then we're up a water. Our weaknesses
Do we have applications that have poorly written code?
Whether we've written those applications in house or we've outsourced them to a vendor, do we have good secure code
Where do we have a code that we're trying, that we're planning to release a patch for later on?
Right. So that's kind of the idea there is.
That's where vulnerabilities are. We would need so many ideas and honey pots and,
uh, you know, intrusion detection systems and all these other external elements if we would just write secure code to start with.
And then we have to really think about that in relation to our Web applications,
because we're gonna allow
external users to access those webs
now. Other vulnerabilities are personnel. If we haven't vetted our employees properly, that's gonna be a big problem. Do we have administrative controls in place?
Do we enforce policy?
A written policy demands enforcement,
or there will be people that don't follow it. So how do we enforce our policy?
are we able to detect changes in their threat landscape?
Can we respond to things that air are
the things that are materialising not just today, because if I'm preparing for today's attack, I'm already behind
now Risk ownership is one of those things that we want to identify, and that's really a significant piece
in addressing risk is making sure there's someone that has the responsibility for it.
Now, the entity that has ownership of a risk must be high enough in the organization
so that they can appropriately address the risk.
You know, down at a certain level, I may not be able to approve funding.
I am not gonna be able to prioritize one department, one process over another.
So, for instance, when we talk about technical risks, we may wind up assigning that to the chief technical officer as being the risk own
right? They're the ones that can that can really make a difference in how that particular asset is protected. So owners should be high.
They've got to be able to prioritize. They've got to be able to sign off, commit to fund and support the risk responses They're ultimately accountable for overseeing and ensuring the responses are tested and her current.
So I t or really information security. We may be responsible for implementing risk controls,
but the business process owner has the ultimate responsibility.
All right, now, the next piece we're gonna talk about is a document called the Risk Register,
and this is gonna be our central location to address risks
to discuss risks. We're going to share this with our risk team
and ultimately this will be sort of, ah tracking mechanism as we move through our projects in our day to day.