As a cyber security analyst, you should understand how to utilize active defensive measures to better
protect your network from malicious activity.
We're going to discover in this episode where those active defenses should come into play, where you
should focus those defenses, and how we can improve detection across our network to better prepare
ourselves to defend against malicious activity.
Throughout this episode, we're going to discover not only those active defenses and improved detection,
but how they're intertwined with another.
To create a better cybersecurity strategy within your organization.
You'd be surprised how often misconfigurations within our network relate back to data exfiltration and
data manipulation within our own networks.
Configurations are one of those human error elements that we see constantly from day to day, that pose
dangerous problems within our network.
You, as a cybersecurity analyst, need to understand that configurations need to be kept up to date.
If I change one portion of my network, then I need to change the other portion as well to match that
so that we're not creating a new vulnerability within our systems.
It also means that I need to change those default username and passwords.
We go through our different new items within our network, and anytime we add, delete or modify something,
we need to look at the opposing or applied different technologies associated with that single change
that we made in that single item.
If I change a firewall, then I need to look at the IPS, the IDs, the router, and any switches corresponded
to that firewall to ensure that I didn't accidentally create a vulnerability within my system, we need
to make sure that we're looking at new vendor requirements as well.
They come out with new items or new, uh, new technology within our network.
We need to go through and identify what does the vendor require with this newest technology, what is
their standard, and are we meeting that standard to make sure that our systems and our requirements
are up to date?
Meeting vendor requirements doesn't sound like something very glamorous, but believe it or not, it's
something that you need to be aware of so that when you go through, our network remains secure.
We also need to make sure that we have secure logins.
Secure logins should be separated.
Do I have an administrative login versus a working login?
You'd be surprised how many people use the same login for everything that they do, and they always
tend to use the highest of the logins.
This is a problem across our networks on a whole.
If I have administrative access, do I need to be accessing that system with the administrative login
to do normal stuff?
It's not uncommon to see somebody with admin access using that access to check their emails, or even
do limited work that doesn't require that admin access.
We need to make sure that our secure logins stay secure and only utilize when they need to be utilized.
Further, we need to make sure that our logins are secure, that we're using a login for each individual
user rather than a group of people.
We don't want one login for five different people.
We'll never be able to tell who accessed what or why they accessed it.
And then we're getting different stories and then minds fade.
We can't go in and go, oh well.
On Tuesday at 8:33 p.m., this user, you did this to our network.
Why did they do that?
You have five technicians that all use the same login.
You're going to be jumping through hoops and making constant phone calls, trying to figure out why
they logged into the system.
And even then, you can't prove that it was that individual user that actually did it.
So you could get a lot of he said she said stuff and you just don't want that.
Misconfigurations provide us with weak login credentials and insecure access control.
Now, we kind of touched on that already, but you need to understand that when it comes to weak login
credentials, we're talking about usernames that may not be exactly what I would call profound.
You want your login credentials to be related to a specific person.
We don't want to pass on our login credentials and we don't want shared login credentials.
Meaning I don't want one person to share their same login credentials with everybody else.
Now I beat that dead horse in our last slide, so I'm going to stop with it on that one.
We want insecure access control to be secured.
If I'm using telnet or I'm using something that's insecure and unencrypted, that's a problem.
That means anybody that's listening in could technically get that login information.
We want to use two factor or even multi-factor authentication when it comes to login.
We want those insecure access controls to be shored up as quickly as possible.
We want open insecure ports to be blocked down when we're not using them.
Yeah, it's great to have Https open all the time and that's fine on a server.
But why am I using HTTP?
What about FTP?
What about telnet?
All those insecure ports?
If they're not being used, let's lock them down.
Let's shut them down so that somebody can't get onto them.
Even if I'm using a port like RDP and it only gets used once in a while, maybe once every 30 days,
I should lock it down and then only open it when I need to.
We want to make sure our encryption is up to date, and that we're using new encryption keys at least
every 30 days for AAS.
We don't want our encryption to be the same encryption key that we've been using for the last five years.
Sometimes it's used to being updated and we want to do that.
We want to make sure our default settings aren't in place.
I can't tell you how many times I see on the news every single month that some Organization got locked
into their system, and a malicious malware got into their system because they used default network
credentials or default settings that just left open a known common vulnerability.
Because when you first log into the system, it's like, oh, access this port, plug in this username
and password, and it gives you full reign to the system.
This is a problem.
This is a misconfiguration that needs to be handled.
And you as a cybersecurity analyst, whenever you're dealing with a new piece of equipment or resetting
a piece of equipment, need to be aware of that.
Within every network we have an isolated network.
Usually this user network is usually used for testing, or it's off grid or it's not connected to the
internet, it's isolated from everything else.
It doesn't even have to be on the main network.
It could just be a subset or a Vlan of that existing network that doesn't really have access to the
rest of our internal workings.
This isolated network can be used for a variety of different reasons, from research and development,
all to shuffling malware or malware infected networks into that system.
It can also be used for hunting bots or honey nets, which we'll get into a little bit later.
But within these isolated networks, we want to provide the same monitoring tools that we utilize on
our live network.
The worst thing that you can do is provide an isolated network and then not monitor what's going on.
We want to understand the baseline within our network, within our isolated networks, to make sure
that we have an understanding of how much traffic is going in and around that specific isolated network.
Again, that comes into play with monitoring and how it's being deviated.
If something goes wrong, we want to do file system and integrity checks via hashing files.
We can do a variety of different tools, like Hashcat or something else that provides us hash values
of those internal workings to where if something changes, we're aware of it.
We also want to do behavioral analysis.
What are they impacting within that isolated network?
Who's accessing it?
What kind of data is being maneuvered?
If we have a behavioral analysis and a baseline of that behavior, then we know what to expect.
And if it changes, then that should set off a problem or an alarm so that we can investigate.
We also want to do manual inspections.
Sometimes automated tools just aren't good enough And I while we love to lean on it quite a bit, especially
as of late, it doesn't do as well as a real analyst does.
And with that takes manual inspection to figure out what's going on and if the system is operating,
how it should.
Isolated networks are the same way, the same tools that we utilize inside our live network.
We're going to try and duplicate those as much as possible.
And those isolated networks, given the cost that's required.
Now we talked about isolated networks.
Let's talk about business critical assets.
These are assets within our network that may have a priority based on what they do for us and the company.
Meaning that if I have a piece of equipment that we utilize that literally makes us $1 million per day,
that would be a business critical asset.
Maybe I've got a server that connects to all my operations and R&D guys, and our job or our company's
job is to research new equipment or new procedures in place.
Those are critical assets that need to be protected.
We need to identify those assets and then put a priority on those assets in the event of an attack or
a problem that's going on within our network, we need to provide continuous monitoring to those critical
assets to ensure they're behaving in the way that we already identified what's going on with those systems.
We need to know if the antivirus alarm goes off and what got into that system.
We may need to investigate something minor that we wouldn't normally look at on one of our other systems,
because it's a critical asset.
If we're not expecting malware to get to our systems and suddenly we have malware, even if the AV took
care of it, we may want to find out how it got there in the first place.
We need to look at behavioral analysis and understand what kind of behavior is the norm on that system,
and what changes.
If it does change, why did it change?
These critical assets really need a more of a Microsoft viewpoint than what we may see on something
else.
We also want to do threat intelligence integration.
If we're seeing trends or threat intelligence that pinpoints to a specific attack or a vector of an
attack, that could put our critical assets in jeopardy, we need to be aware of it, and we need to
put in those mitigating factors as quick as possible to defend against those types of attacks.
Threat intelligence, integration really comes into play as a holistic viewpoint when it comes to critical
assets.
We just need to pay attention to those assets a little bit more than what we would on a normal client
infrastructure.
And then finally, vulnerability management.
We want to may want to scan those critical assets more than we scan other devices on our network.
We may get away with scanning our normal PCs or operating systems or clients, maybe once a month,
maybe once a week.
We may want to look at our critical assets and double, if not triple, the vulnerability scanning that
we do on those assets.
We want to be understanding of those vulnerabilities as often as possible, and as soon as the new vulnerability
pops up, we want to rescan it.
We want to make sure that our library is up to date.
And if we update Nessus or Openvas with a new attack, vectors or new problems that they've seen, we
want to rescan those critical assets as soon as possible to make sure we are not in danger of exploitation.
Now, we talked about research and development, but did you know, as a cybersecurity expert or as
an analyst, we can do our own R&D.
This is usually comes into play with honeypots and honey nets.
These are virtual Well most of the time virtual machines that correspond on our live network and look
exactly like a live network or a live client that's operating on our network.
This provides us with a glimpse of what attackers may be after we can set these honeypots or honey nets
up to be as realistic as possible, so that we can track and monitor what's going on within them.
This means that if I've got a fresh attacker that's coming into my network and they get into my honey
net, I can track what's going on within that network and identify how they're getting in, what they're
interacting with, what attacks they utilize.
And it can also provide me a little bit of early detection against my own network.
No one should be on my honey net.
A lot of that traffic is going to be simulated so that the attacker doesn't realize what's going on.
But if we suddenly see an attacker going in there and we can monitor their activity, then it could
provide us some leverage or some key notes that we can then utilize within our live network to see if
anybody's taking the exact same advantage that we want our honeypots and honey nets to be as close,
as realistic as possible, because we want to fool those attackers into thinking they are really invading
an actual network.
This provides us early detection as well as research and analysis of what's going on.
We're providing deception by telling the attacker that they this is a real network, and there's real
things on there that you can download.
Now we want to make it as as as realistic as possible, even by providing semi tangible assets in there
that they may want to download or exfiltrate.
That doesn't mean that we shouldn't make it gobbly goop or make it misleading.
That's fine.
We're going to use deception to understand where they're coming from and understand how they got into
our network in the first place.
This also provides us that threat intelligence that we can then share within our own organization or
outside of our organization, within that research and analysis of the different attacks that a malware
or malicious actor is utilizing within any network, we want to understand active defense.
Active defense is actively defending our network against perceived dangers or threats.
This means that we want to go through and actively defend against threats.
This means using threat hunting as an atmosphere.
We're going to go through and we're going to actively pursue different threats or alarms or alerts on
our network.
We're not just going to let them sit idly by and expect our automated services to take care of it.
We're going to use deceptive technology like honeypots and honey nets to try and get more research and
development, or research and analysis of what's going on within our networks by providing that R&D
or that research and analysis within a honeypot or a honeynet.
We can more actively see what's going on and perhaps identify if that is going on within our live network
as well.
We want to provide incident response when an incident occurs.
We want to respond to it accordingly, whether from a priority of high or a priority to low.
We want to track that incident response and go through the motions, just like we would with every single
attack.
Now, obviously I say every single attack, but that's just not going to be the case.
Sometimes we'll have an AV that just wipes it out and we're too busy that we can't get to it.
But if we're seeing an attack in motion that is taking advantage of a vulnerability and properly exploited
it, we need to respond to that in the proper way.
We want to do threat intelligence sharing with other companies, organizations and governments so that
we get the most latest and updated information so that we can understand what's going on, not only
with other networks, but what could perceive to be happening within our own network.
And finally, we want to actively monitor our network.
We have monitors all over the place.
We have logs every time we access an IP, every time you go through a firewall or an IPS or even a client,
it produces a log.
We should actively be monitoring all these logs within a system to figure out what's going on within
our own networks.
This can provide us clues and gateways into malicious activity on our network, and by not actively
monitoring it, we could be putting ourselves in pure danger from an attacker.
Whether it's a denial of service or even a ransomware attack.
We need to provide an active defense and as part of that active defense, provide a concerted effort
with a holistic viewpoint, not only within our own organization, but with other organizations as well.
We need to provide threat intelligence feeds from not only the government, but other organizations
and individuals that are like minded with our own to properly provide a defensive structure and active
defense within our network.
As a whole.
Within the CSA exam, you can expect to see high level questions specific to active defense and focused
defense, with some subsidiary questions on improved detection methodologies.
A lot of your improved detection questions should have already been covered in Security+, but don't
underestimate the fact that they will probably appear in Cisa as well.
We should expect to see scenario based questions specific to everything we discussed today.
Expect to see questions like, hey, what type of active defense would you utilize in this scenario?
If I have a legacy system that utilizes this operating system, what critical component would utilize?
I would not expect to see questions like that.
When we go through the exam, I would expect to see questions at a high level that talk about proper
configuration and why it's important.
You may get questions as to hey, for username and passwords, would you utilize a SSL or a federated
sign on, or would you utilize an administrative password for everything you do?
These are basic questions that you should have a basic common knowledge of when you go through this
exam.