As a cybersecurity 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 intertwined with other to create a
better cybersecurity strategy within your organization.
You may 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 the 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 IP S, the I DS,
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.
There you 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,
it's not uncommon to see someone 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 utilized 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, why they access it.
And then we're getting different stories and then minds f
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 gonna be jumping through hoops and making constant cold calls
trying to figure out why they logged in the system.
And even then you can't prove that it was that individual user that actually did it.
So you can 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 insecured 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 multifactor authentication when it comes to login.
We want those insecure access controls to be short up as quickly as possible.
We want open insecure ports to be locked 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, tell that
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 on to 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 a,
as 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 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 bower gone into their system because they
use default network credentials or default settings that
just left open a known common vulnerability.
Because when you first log in the system, it's like oh
access this port plug in this username and password
and it gives you full range of 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 year
work 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 an isolated network can be used for a variety of different reasons from
research and development all to shuffling the
malware or malware infected networks into that system
can also be used for honey
Os 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
uh 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 files, system and integrity checks,
the hashing files,
we can do a variety of virt tools like hashcat or something else
that provides us hash values of those
internal workings 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 A 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,
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 a million dollars per day.
That would be a business critical asset.
Maybe I've got a server that connects to all my operations in R and 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 V 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.
But 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 may want to scan those critical
assets more than we scan other devices on our network.
We may get away with scanning our normal P CS 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 uh understanding of those vulnerabilities as often as possible.
And as soon as a 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
NSES or open
boss for the 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 and D,
this is usually comes into play with honeypots and honeynets.
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 honeynets 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 honeynet,
I can track what's going on within them
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 Honeynet.
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 that 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
same advantage of that.
We want our honeypots and honeynets 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 uh as, as realistic as possible, even by providing semi
tangible assets in there that they may want to download or
trade.
That doesn't mean that we shouldn't make it doubly
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 their network in the first place.
This also provides us that threat intelligence that we
can then share within our own organization or outside
of organization within that research and analysis of the
different attacks that a malware or malicious actors use li
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 gonna go through,
we're going to actively pursue different threats
or alarms or alerts on our network.
We're not just gonna 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 give
more research and development or research and analysis
of what's going on within our network by
providing that R and D or that research and analysis within a honeypot or a net.
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 priority 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 A V that just wipes 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 act,
monitor our network.
We have monitors all over the place.
We have logs every time you access an IP,
every time you go through a firewall or an IP S or even a client, it produces a log.
We should actively be monitoring all these logs within a seam
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 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
likeminded with their own to properly provide a defensive structure
and active defense within our network as a whole.
Within the cys A exam, you can expect to see high level questions specific to act
defense and focused defense with some
subsidiary questions on improved detection methodology.
A lot of your approved detection questions should
have already been covered in security plus,
but don't underestimate the fact that they will probably appear in coys A 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 make a question as to, hey, for username and passwords,
would you utilize a SSO 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?