all right now, once we move past conducting the pin test from the technical perspective, now we have to kind of look at our results and figure out what they mean. And often we've got all of this data to analyze, and it could be difficult to make sense out of.
That's why we'll use some of these utilities to sift through what's meaningful and
and what's not. But what we're looking for us. We're looking for trends, you know? Do we see any sort of pattern of vulnerability on our network? Do we see certain departments more vulnerable than others? Do we find that they're disjointed operations between departments or any sort of conflicts there? Um,
in what we've got to do is we've got to find a way to solve these problems.
Ah, using judgment to solve difficult problems as a very wide topic. But when we're troubleshooting, we've got to think about you know what allow this problem to take place, and how do we make sure that we learn from our mistakes and that we move forward? Document document documents certainly is part of a pin test.
Every pen test should close with lessons learned in a review and not just pen tests, but every attack, you know, you're gonna be susceptible to attacks. Hopefully, they don't get through. But if they do, we gotta learn from it. Pull our team together. We debrief them, we interview them for information.
We gather that information from our subject matter experts, people on her team,
and we figure out how to move forward on how to be successful in the future. Now, when we're doing this analysis and testing I've already talked about, we're gonna meet with our staff. Uh, we're gonna meet with senior management. We're gonna find out why we're conducting the test, and there are a wide variety
of reasons we would conduct the test, you know,
not the least of which that it shows my due diligence that we might be required to certify products and part of certification is to do the technical evaluation. What are the reasons that we're doing this? We want to make sure that we are testing in such a way that it is beneficial again,
everything comes back to this cost
benefit analysis. So how often do we conduct conduct pin tests? What type of pin tests do we outsource? Do we do it in house? It all comes down to cost benefit analysis, pros and cons. All right. Ah, big thing that we're trying to do is figure out what is the effectiveness of our existing security mechanisms.
as a result of a pen test, we figure out, Hey, what usedto work five years ago is no longer effective, Fourth or more. Realistically, what happened? What? What we had in place yesterday is not effective for us anymore. The environment is constantly changing. Attacks are constantly changing.
We have to stay on top of things. We have to continuously review and monitor our network. So just because we have implementations in place today and that, honestly, is one of the big things that I see companies failed to do is continue to test and continue to evaluate.
Are the mechanisms we have in place
still effective? Ah, lot of companies have the mentality of if it ain't broke, don't fix it.
And, you know, um, we talk about wept a little bit in the crypto chapter, and, uh, I think we might talk about it in a later chapter, but at any rate, Web wired equivalent privacy Web is a train wreck, a sw far as a security protocol.
It actually takes me longer to open up the utilities to break Web
than it does to break Web
and surely weapons obsolete. No obsolete would mean no one's using it. And you would be shocked that the number of organizations that still have their 802 11 be access points and routers in place, and their motto is, If it ain't broke, don't fix it.
Well, Webb's been broken, and it's been broken frequently and easily. Just because it hasn't been broken in your environment doesn't means not gonna be, and it's just a matter of time. So what we find is, even though that may have been the best game in town 10 years ago, it's certainly not the best game in town today.
So the security configurations that were once very effective
may have outgrown their usefulness. We need to continue to evaluate our existing security configuration.
another reason that we do this analysis in this testing is we might have new solutions we want to put in place, and we know vendors are always going to sell a product, but we want to find out if that products gonna fit our security needs in our current environment. So
before we would push something out before we would bring it into operations or push it onto a production network,
we're gonna go through a very thorough testing system
Now, reverse engineering. This is essentially breaking an operating system or, uh, you know, a lot of times it is geared in operating system, but it's essentially Can I take it apart and put it back together, Uh, with creating some security vulnerabilities in there.
This requires a relatively high degree of skill to do that reverse engineering.
But your developers and programmers are often quite skilled with thes techniques. And really, what we're doing here is we're attacking the architecture of a particular system, hoping to cause a security vulnerability.
All right, other things that we want to do as faras analyzing our network and making sure that we have the information necessary to detect and to rebuff an attack
is we want to know what normal network activity is. We want to know what we expect out of our network. And often we were We refer to that as a performance baseline
So maybe my critical servers. I want to know what processor utilization is on my critical servers, so that when there's something out of the ordinary, I'll know it after know what's ordinary before I know what out of the ordinary is. So we're gonna have these benchmarks, these levels of expectations for performance,
and we want to make sure that that's documented so that if anything's outside of the normal will be able to detect it.
Performance analysis is a big part of security analysis, because when you think about things like denial of service attacks or when you think about ah, worm on the network bouncing from host to host to host, what should network traffic look like? What should our normal network utilization be?
anything outside the norm might be an indicator that there's an attack. So we monitor performance and we monitor the network, and we know what we expect so that when the unexpected comes, we can look at the good say, this may be an indicator of a problem.
Okay, network traffic analysis again can be sniffing the network, capturing packets on the network
devices like protocol analyzers. That's their job. But We also talked about intrusion detection systems
really just being glorified sniffers that capture packets but then have an analysis engine. We'll talk more about intrusion detection in host an application security module. But ultimately we've got a look at what's on our network
from our users, as well as potentially from Attackers. Often, like I said, problems start inside, and they're not always malicious If I have users. Using outdated applications generate a lot of broadcasts that might cause a performance issue
if I have users using outdated applications that use outdated protocols may be transmitting
ah, passwords across the network in clear text. They don't even have to be outdated protocols. Many people still use FTP. Many people use telling that, uh, with UNIX, people may use the our utilities, like our log in. All of those transmit credentials across the network in clear text.
I've got to find out if that's going on.
So analyzing the packets on my network through sniffing or through intrusion detection intrusion prevention systems would terminate the attack. We gotta look at what's going on on our own network.
So ultimately, this particular network in the chapter rather is all about assessing our internal network. We're looking for weaknesses. We're looking for vulnerabilities. If I don't know what vulnerabilities exists, I exist. I can't find them and I can't protect them.
We'd much rather find our own vulnerabilities
than have an attacker find and exploit them.
So when we talk about the steps of conducting a vulnerability assessment, making sure that we know what our purpose is, making sure that we know what the rules of that vulnerability assessment are because pen testing vulnerability assessments can be disruptive to the network can be destructed. Never our goal. But they can be.
So we always make sure we have signed off from senior management.
We followed the rules. We use the tools that they specified. We're looking for weaknesses so that we can provide a report to senior management on what we found.
Then it's up to senior management to take that information. We've done the due diligence. We've researched the weaknesses. Now it's up to senior management to use do care
and implement strategies to close those weaknesses again. The cast exam doesn't require you to use certain tools or to do certain things as part of your vulnerability assessments and pen tests. You want to be aware of good business procedures and good business practices
and also to know that vulnerability and assessments and pen tests are much bigger than just
technical security controls. So hopefully this has been a helpful chapter in outlining the need and purpose as well as the procedures for conducting vulnerability assessment pen test not a real technical level, but more from a conceptual and administrative level.