Hey everybody welcome to the next video.
We're gonna be talking about identifying and how to rank business risk on the findings from an assessment.
Now a quick thing on what business risk is it is in some cases a level approach in others a feedback
approach.
But we're gonna be doing over the level as is the most common that you'll find is when you have an issue
of some kind some vulnerability some issue that was identified.
There is supposed to be some sort of business risk associated to it.
Now the assessment as a whole can also have an associated risk from the business perspective on that
particular engagement itself.
Now when it comes to leveling the risk There's normally two different types.
Now you're gonna have ones that when somebody identify the risk they're doing it from from no knowledge
of the infrastructure such as a consultant from the outside.
And then you have the business risk assessment and level associated to that finding on against somebody
who internal like an internal red team that knows a full amount or a full amount of the infrastructure
or a large amount of it.
So they can make the justified risk associated with the finding a little bit better than a cut than
a contractor might because they know where everything kind of plays in and what the true scope of whatever
that issue was internally.
Now in some cases a contractor might be able to provide the same level of detail depending on how far
they pushed the actual vulnerability.
But in most cases if it's popped a box off to the next one then you're going to have a limited knowledge
of the infrastructure.
By that point and how everything kind of works together in some things like how services connect might
not be relevant to the contractor but it is to the red team.
So just keep that in mind no when you're a contractor your risk assessments can be based on whatever
metrics or rubric that you happen to have.
And from a Red Team you should have an internal one but it's always a judgment call based on another
person on the team reviewing things as well because that should always be done regardless of how senior.
And then also double checking with your own rubric because there might be some instances where local
privilege escalation might be considered low instead of a medium or high now low risk.
Now what are some examples of low risk.
So you're able to manipulate a few things but you don't have any code execution issues.
That tends to be on the low side.
Out of date versions of stuff without exports available tends to be on the low end or informational
level weak file permissions that don't allows you to raise any privileges but maybe you can see something
you probably shouldn't be able to but it doesn't provide you any any leg up on the competition or on
attacking a machine that would.
Are some examples that you consider as low risk now for medium.
If you have such as like default credentials on a web app that have no code execution you can't gain
access to the box.
You just have access to a web app.
You can change some settings around and that's pretty much it.
And that can change depending on what the the application is doing.
If it's a live production machine and you can start and you can turn out all the traffic all the traffic
as an example then this would be a much higher risk.
But depending on the web app cross-eyed scripting tends to not be a giant high priority for a lot of
people.
It's very useful for an attacker's perspective but again not not a high level of risk there from a generic
standpoint.
Now keep in mind I'm providing these risk assessments based on a contractor's perspective because you
need to know the infrastructure that we're talking about to be able to do it from a knowledge perspective.
So Elif local file inclusion without any code execution available so you can read small files here and
there maybe a config file but you can't really get onto the machine with the information you have because
it's so restricted to the user.
That would be where an instance of medium.
But if you do L5 and start pulling in ATC password or start getting code execution now you're considered
at the high level for the same issue but you see how that transitions pretty quickly.
Then we have high risk on authenticated remote code execution market is high.
It's never a good thing to leave that open you never know when it's gonna be used by somebody privilege
escalation if you can go from user to route it's automatically high if you can get administrator access
to route access in any way whether that's through a password that's been dumped somewhere or that you
found a password on a file or whatever the case is it's high it needs to be resolved now and any lateral
movement could you use this machine to pivot to a different network.
That's a problem.
They need firewall rules in place IP tables they need something to not allow you to pivot through the
network like that.
So understanding how to put all this together and identify each issue found in the risk associated with
it will make it a lot easier for you when filing tickets or presenting it to a customer on what needs
to be fixed.
What's the most important thing that they should be working on first and what they could realistically
leave for next quarter or the next six months down the road.
Ideally everything on the list should be fixed of course but you need to rank things appropriately in
what you need to or what you believe as a as an expert because they're paying you or whether you're
internal or external to the organization you or they are paying you as an expert in this field or a
subject matter expert to provide them what should be fixed in one.