In this episode,
we're going to talk about software vulnerabilities
and what constitutes a software vulnerability.
We're also going to talk about static versus dynamic analysis and
why it's important that you understand the differences between them.
Then we're going to go into reverse
engineering and how static and dynamic analysis play
a role in that reverse engineering of different
malware and software that you may see.
Finally,
we're going to talk about fuzzing and what that constitutes in order
to test your software vulnerabilities throughout your cys A exam process.
You need to be aware of these different terms. But don't worry, you don't have,
have to know coding to pass this part of the course.
Cys A isn't actually going to make you go through and dissect
a piece of code or malware to figure what's going on.
You just need to know all the high level overview of what we're talking about today.
And you should be good to go when it comes to your CYS A exam.
When we look at software, you must understand as an analyst that every
software has the potential for vulnerabilities.
Software is created by people and human error usually makes
up a majority of the problems that we see,
not just within our enterprise environment
but within developers as well.
Codes can sometimes be as little as 10,000 lines long,
sometimes a little bit less up to hundreds upon hundreds of thousands of code lines.
When you link of different software programs realize that something
like a calculator may only have 100 lines of code,
but a video game can literally have millions of lines of code.
This puts a major detriment to software vulnerability on the line.
And you as an analyst need to be able
to understand how do we discover those different vulnerabilities?
We're gonna talk about discovery as our first phase.
What do we go through and how do we discover those different vulnerable?
This is usually done via a scanning process.
Now we're going to go into the detail in the next slide,
exactly the different types of scannings that we can do, but just under scanned.
In order to identify and discover vulnerabilities,
we must conduct a scan after the scan has been completed,
we may identify and analyze that scan process to discover those vulnerabilities.
Once we have identified and analyzed that vulnerability,
we decided where it needs to go from there.
We need to remediate the vulnerability.
Sometimes we need to throw a band aid over it to provide a short term solution.
This is usually done in a variety of different ways.
It's a web application,
maybe we'll throw a web application firewall on there
to provide a temporary aid to that vulnerability.
However true remediation for software comes into play that we have to
rewrite the code in such a way that it is secure.
Next, we need to validate it.
When we validate that code, we're going through the process and re scanning it.
We're validating that that vulnerability is no longer there.
And finally, we need to document it. I've pounded on this before.
But documentation, documentation, documentation,
you're never going to have too much documentation when it comes
to identifying and remedying a vulnerability
or any process within cybersecurity,
annotating our vulnerabilities and documenting the process is the number
one thing that you can do as a cybersecurity analyst,
especially if you're an expert in the field.
When we conduct an analysis of our code,
we're usually either doing a static analysis or a dynamic analysis.
A static analysis is examining the code without actually executing it.
This goes through an automated process of looking at the code from a line by
line perspective to automatically look for different vulnerabilities
associated with how the code is run.
Now, this is from a code review.
A code review is where we go through and you actually have a
human being looking at line by line of code one line after another,
usually require an expert developer or coder to go
through the process in a static examination or analysis.
We're not really using a coder but we're using a series of automated processes
to look for different vulnerabilities associated with
that code without actually running the program.
This is different from a dynamic analysis and
a
analysis.
We're running the program,
we're seeing what happens as the program runs through its features.
We're examining the task process.
We're seeing how it interacts with the
different processes both on the operating system
and the other programs or applications on the machine.
Static analysis is usually more effective because it's going
through the code without actually running the program.
With this sense,
we're actually able to see the coding as it's going
through and we're able to create automated processes to identify different
abilities on a line by line basis.
This provides us an early identification of how the code is going to interact
with the operating system as well as the other applications that the code resides on
dynamic analysis and comparison is less effective. But it's a lot quicker.
We get to identify how the code interacts through
the other applications and through the operating system by
examining that code or that program while it's being
initiated and while it's executing through its program,
imagine you will, if I start up a calculator and I plug in the buttons of one plus one,
we expect an output of two.
But if I'm going through that process through a dynamic analysis
and it's intersecting with a different program for no reason that would be dynamic
analysis where we're looking for different tidbits
as we're using the program static analysis.
On the other hand is where I don't use the calculator,
but I look at the functions that the code provides,
showing me that two plus two would then output an identifier of four.
This is the major differences between a static analysis versus a dynamic analysis.
Reverse engineering is a subset of the static analysis process we've
gone through and we've analyzed the code on a line by
line basis based on an automated process that
allows us to identify different perspectives of the code
and how it affects both the operating system and
other applications that reside on that operating system.
We can then reverse engineer the process to see exactly where it comes into play
to see where it's going wrong
and where it's intersecting with those other
applications or where it's going on with the
process of acting in a form or function that we
didn't anticipate or that we don't want reverse engineering entails
meticulous examination of the product in order to understand the
functionality and the operating mechanisms that reside on the program.
We're literally going through the code to reverse engineer what it did.
This is much like filling a glass of milk.
The program fills the glass of milk up with milk, right?
We're literally pouring the glass.
How would you pour the glass of milk out and understand how it actually got in there?
Did it come from a jug, did it come from another glass?
Did it come from another of a container? Did it not come from a container at all?
And just suddenly start dripping in there?
This is reverse engineering really comes into
play and why it's so difficult to achieve
this reverse functionality reveals to us different aspects
of the program and how it really pulls off
the different malicious activities that it intersects with the
regular programs on a case by case basis.
This allows us to have a deeper understanding of how the code interacts,
not just with our applications, but with our operating system as well.
This is the only true level that we can
understand malware and how it intersects with different systems.
You have to remember that through dynamic analysis we're going through and we're
the processes that come into play.
But in some cases, there may be a timer on that process,
we could start the program and then shut it off an hour later.
That didn't really show us that there was another layer to that.
And in three days time,
that same program would have released any
more malicious ransomware onto our systems.
This is why static analysis and reverse engineering are prized in cybersecurity.
Finally, there's something called fuzzing.
Fuzzing is a method that we employ to uncover software flaws through normal means
I want you to imagine that you have this brand new piece of software.
Let's say that you created this calculator and this calculator is working great.
It does all the pluses and the minuses we can subtract, we can add,
we do everything that a calculator is supposed to do
and we can even do some algebra.
The algebra function is a major initiative to increase our calculator standing.
However,
how do we truly test that we could throw in basic
algorithms that test the algebraic function of our new calculator?
But how does it intersect with data that we're not expecting?
After all, we're expecting a calculator function
and an algebraic function within that calculator to produce an output.
What happens? However, if I just throw a bunch of letters at it, let's say
we throw in a bunch of keyboard trash.
I want you to imagine having your cat dance on the
keyboard and then we submit it to that calculator program.
That's where fuzzing comes into play.
We're literally just throwing garbage at it to see how the system
interacts with this random assortment of information that we throw at it.
Now, there's different fuzzing tools that we can utilize.
But what the fuzzing process really does for us is it validates if we have a flaw
or if that the program is capable causing
a software freeze crash or exhibits unexpected errors.
It also lets us know if there's an output that through that fuzzing process
allows us as an attacker to gain rudimentary or root access into that system.
Buzzing is a great way of throwing garbage and subsets of coding into the system.
To see what the output is.
Imagine if you will just throwing a bunch of garbage and
all of a sudden you have root access into the system.
This would be a major vulnerability and we need to test for that vulnerability.
In this episode. We talked about software vulnerabilities.
We also talked about how to test for
vulnerabilities through a static and dynamic analysis.
We talked about the differences in how dynamic analysis
while more efficient isn't as accurate or in depth.
We talked about reverse engineering and how it's a subset of
static analysis where we're actually reversing the process of the program.
Finally,
we talked about fuzzing and how fuzzing interacts and
throwing garbage at the system in order to see the
output and how that output interacts with the program
in which we're testing always come into play.
When we're talking about software vulnerabilities and how to test for them.
In the cysa
exam.
You can expect to see scenario based questions relating back to the
fuzzing process as well as reverse
engineering and static versus dynamic analysis.
You should understand the differences between them and be prepared
to answer scenario based questions that relate to each one.
You might see a question that talks about
software vulnerability testing and fuzzing is one of
the answers I want to caution you from
jumping straight into that vulnerability of fuzzing.
Sometimes the question is related back to a normal standard
or in different type of testing that we're conducting,
you should know what fuzzing is and
how it interplay with software vulnerabilities.
But you should also know the difference between static and dynamic analysis.
I'd caution you from jumping straight to the right answer.
Remember when you're reading any type of exam question on cys A to read the question,
read the answers and then reread what the question is actually asking for.
If you can do that,
you should be successful on this as well
as the other episodes that we've talked about.