So as we move into security testing, first of all, we look att, two main types of testing white box testing and black box testing. Sometimes white box testing is referred to his clear box testing or structural analysis. The reason it's called Clear Box or White box
is the idea that the source code is fully visible.
As a matter of fact, the tester is another programmer that has access to whatever they want. Any sort of supporting the documents for design. They'll have access to source Coast code, any sort of use and misuse documentation, configuration files, whatever they want, they'll have access to.
What they're really doing is they're checking under the hood
once again. Is this well written code? Is it structurally sound? Is it logically sound?
Is it written the proper way and again, considering that from a security standpoint
now, the opposite of white box testing is called black box testing
and the idea here is that there is zero knowledge and sometimes it is referred to as a zero knowledge test. There is zero knowledge of the code to the attacker, so the attacker has no additional information and they're gonna have to go through just like a normal attacker that has no inside knowledge.
And they're gonna have to go through a series of tests
often related around, you know, the world of brute force tests to see if they can create a compromise. Some of the black box testing techniques might be fuzzing scanning or penetration test.
Ah, fuzzing will just mention first because we talked a lot about code injection and we've talked about within our applications that elicit input from users through the use of forms. We have to make sure that those forms are safe,
that they're secure and that they don't allow input that could be damaging on the back end.
That's what Fuzzing is all about,
sometimes called fault injection, because that's what we're doing is we're injecting faults over and over and over slightly different variations to see if any of them will be successful. So ultimately, we're injecting faults into the software, and we're looking to see how the software response and this is called fuzzing
and what it's ultimately about. What I think they'll focus on for the exam
is it verifies our input validation. Is it good enough?
Do we have software which could then be injected or commands can be injected or some sort of malicious code. Or do we have an application that can withstand that type of attack? And we refer to that as fuzzing.
It's all about verifying software, so we would also look for defects in coding. We would also look for any sort of other known security plugs. Ideally, we could detect buffer overflow errors and a buffer. Overflow error is any kind. More information is written to memory,
then is allowed to be
thus overfilling the memory buffer, spilling its contents into something else. Maybe the buffer for another application.
Remote code, execution. You know, there's always risks. Associated are always risks associated with remote access, so executing code from a remote location
through the use of input into an application could be very dangerous. We're also looking for faulty logic pore structure, those things that we would be concerned with,
uh, that we're gonna use fuzzing to detect
now scanning. We hear about scanning a lot when we talk about vulnerability assessments and penetrations at testing. So with scanning, what we're gonna look to do is we're gonna look to gather information. Scanning is a passive means of gathering information. So what I'm gonna do is I'm gonna scan the network.
I want to figure out what your environment is.
I'd like to know what your I P address and schemes are. I'd like to know you're naming conventions. I'd like to know where your critical servers are. I'd like to know what ports are open. I'd like to know what software is running. I'm looking Just gain all the information I possibly can,
but I'm not making any modifications. I'm not injecting anything into the data stream, so we still consider standing to be passive in nature.
So different types of scans we might do just a general vulnerability scan. So we're looking for some of the known flaws and seeing things like our common ports open. Is port 80 open on your system? Are you listening on the port for web traffic?
Have you patched? The system doesn't have the latest update. Those sorts of things
we can also scan for contents s so that we can actually get through,
to the actual content of web pages. We can scan looking for the contents of not just a word file, but that Macron's within that file. You know, viruses very frequently traditionally have been spread through Mac rose and files, and that hasn't always been
an element that's easy to scan. Now. We do content scanning
so that we can determine if there is an embedded a virus or some sort of malware there.
We got a look and see. Are we exploiting the privacy of our employees of our customers of our patients, whatever that may be? So when we're scanning for privacy, making sure that those violations don't exist
now penetration testing is gonna take all of this one step further. And sometimes we refer to penetration testing as pin tests.
Pen tests are active where his vulnerability scanning is passing.
So with the pen test, we found her with the vulnerability scan. We know what vulnerabilities there are. The pen test wants to take it a step further and say, Can I exploit these weaknesses
Now? Penetration test normally follows four steps. The first step is the reconnaissance step.
What information can I gather often from publicly available sites? You know, can I go to a website and learn information about your organization? Can I goto who is and find out you're addressing Seymour your domain name. What information is out there that's publicly available
on often? There's quite a bit through the use of publicly available sources
from there. I want to look and see. Can I exploit those vulnerabilities? Can I access an open port or take advantage of a system that hasn't been patched? How can I access the network? So in the resiliency piece, this is where the actual attack happens. Now, once I've been successful with my attack,
I want to remove any sort of indication that I was there. So
I'm gonna clean up any sort of evidence. I'm gonna race entries and audit logs I'm gonna remove. Or if I leave software behind, maybe backdoor software. I'm often gonna rename my software to that of a legitimate service. I'm gonna spoof the name so that
if you do go through and you're looking at your processes,
you're gonna see something that you would expect to see anyway.
All right, And then at the end of the pen testing, we're gonna do our reporting and our recommendations. So what we found as faras where the vulnerabilities are, But we're also going to report on any sort of non compliance with organizational policy whether policies are working or not, whether they're being followed.
So those elements are gonna come to us from, ah, scan of the network. That scan is gonna give us vulnerabilities, will take that scan of step further through pen testing.