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 for software vulnerabilities throughout your Cisa exam process, you need to be aware
of these different terms.
But don't worry, you don't actually have to know coding to pass this part of the course.
Cisa isn't actually going to make you go through and dissect a piece of code or a malware to figure
out what's going on.
You just need to know the high level overview of what we're talking about today, and you should be
good to go when it comes to your Cisa 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 think 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 going to talk about discovery as our first phase.
Where do we go through and how did we discover those different vulnerabilities?
This is usually done via a scanning process.
Now we're going to go into detail in the next slide.
Exactly the different types of scanning that we can do.
But just understand 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've identified and analyzed that vulnerability, we've decided where it needs to go from there.
We need to remediate that vulnerability.
Sometimes we need to throw a bandaid over it to provide a short term solution.
This is usually done in a variety of different ways.
This is 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 rescanning 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 remediating 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 different 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, and
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 dynamic 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 intersects 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 vulnerabilities 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, if 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 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 seeing 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 a more malicious ransomware onto our
systems.
This is why static analysis and reverse engineering are so prized in cyber security.
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 can do everything that a calculator is supposed to do, and we can
even do some algebra.
That algebra function is a major initiative to increase our calculator standing.
However, how do we truly test that?
We can 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 of 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.
Fuzzing 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 Cisa 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 interplays 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 Cisa, 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.