[MUSIC PLAYING]
All right.
So in this video, we're going to talk
about what our primary goal is for having
a secure architecture and how we can
utilize different strategies to reach that goal.
So first of all, our goal with a secure architecture
and in the process of properly designing
that secure architecture is to minimize the attack
surface of our environment.
So let's break that down a little bit.
The attack surface is essentially
what's available for an attacker to attack, or compromise,
or attempt to, at least.
That is the attack surface.
What can an attacker target?
This can be any server, any endpoint, workstation,
network device, thermostat, doorbell,
anything that's connected to the network,
anything especially that is publicly
available on the internet that greatly increases your attack
surface.
But anything that's available for an attacker
to attack without being properly secured
and having proper controls on it-- that's what's
known as your attack surface.
Your attack vector-- that is essentially the way an attacker
can come in to your environment.
Do they come in through email, through a phishing message?
Do they come in through an unsecured port on the firewall?
That is another component of the attack surface,
is how they can get in.
That's known as the attack vector.
So our goal here is to reduce our attack surface.
That is, and then, in turn, reduces the available attack
vectors as well.
Reducing one reduces the other.
You can reduce the attack surface
by reducing the vectors.
And in turn, you can reduce the attack vectors
and minimize those, which then does reduce the attack surface.
So it works kind of both ways.
There's a lot of different methods
you can employ to accomplish things like this.
You can do things such as a device hardening,
like hardening your servers, or your workstations, or really
any other device on your infrastructure.
Hardening involves disabling things,
uninstalling pieces of software that aren't needed,
changing default passwords, closing unused ports,
things like that, anything you're
doing to make the device itself as
secure as possible while still maintaining that functionality.
You can minimize what is publicly
accessible on your network.
If it doesn't absolutely need to be
accessible to the entire world, don't have it
be publicly accessible at all.
Don't open anything up through your firewall
if you don't specifically need it.
Don't put a server in the DMZ if it doesn't need to be there.
Only do what is needed for the business
practices in your organization.
Another good way to reduce the attack surface
and minimize your attack vectors there
is to implement a multifactor authentication
solution because, yes, your users can be an attack vector.
Your users can also be considered
part of your attack surface.
There's many different things that
can go into your attack surface and many different ways
and many different areas that could be considered an attack
vector as well.
Multifactor authentication can definitely
help minimize your attack surface.
Implementing a proper vulnerability management
program and a risk management program will also help this.
The less vulnerabilities you have in your environment,
the less things there are for an attacker to exploit,
so naturally minimizes the attack surface there.
Then deploying all kinds of security controls
and countermeasures, whatever's appropriate
to your environment--
if you have email that is on-premise,
then you want to do various different types of email
scanning, from just scanning for spam messages
to checking URLs in emails and attachments,
including on your outbound mail, all of that.
It's an example of security controls and countermeasures
that are based on what you have in your infrastructure.
So that whole risk management and threat modeling
has to come into play before you can really
know what ways you can really reduce your attack vectors
and minimize the attack surface.
So some of the ways that we can achieve our goals
with a secure architecture--
one of those is known as secure defaults.
Now, when you have a new system, they're
not really that secure when they're brand new.
By default, systems are made to be--
vendors develop and sell systems and programs and servers
to be more usable than they do to be more secure, unless this
is specific security program.
So by default, most new systems like this are not secure.
They might have standard default passwords that
are published on the internet.
They may have services that you don't
need that are enabled because they
want to make the experience as user-friendly as possible.
These new systems are built for user-friendly deployments,
but are not built for security in mind.
Now, some of this is starting to change a bit,
and we see in the industry.
But still, this is one of those situations where
Trust but Verify is important.
If the vendor says, this device is hard
and this device is secure, OK, cool, I'll trust what you say.
But I'm going to also go and verify this information myself.
But just keep in mind that a lot of these systems,
out of the box, are built to be used,
not necessarily built to be secure.
So secure defaults-- we introduce that term here--
it's basically, all systems are starting
in a very secure configuration.
And as you determine what is needed out of that system,
you start to loosen those restrictions a bit
as you need for functionality on the system.
This is going to be part of an overall risk management
process, and also part of an overall change control process
and change management process because you
need to make sure you're documenting and communicating
all of these changes as they're occurring in the system,
or as you're introducing the ideas of them changing
in the environment.
So the concept of secure defaults
is starting off ultra secure but loosening those restrictions
as needed for functionality purposes only.
Your overall goal there-- again, starting the secure manager--
secure manner, not manager, and when most of your functionality
is going to be restricted.
Most of the access is going to be restricted.
Then you intentionally release a lot of those restrictions,
or what restrictions you need to release, to the point
where the system actually becomes useful.
So we talked about system hardening here.
This goes hand-in-hand with secure defaults.
Again, most systems don't start out with very strict security.
They're built to be more functional
and have more user-friendliness built into them directly
out of the box.
There's a lot of tools you can use,
a lot of techniques you can use, and certainly
a lot of best practices and frameworks
to help reduce how vulnerable these systems are.
So your goal here is to reduce that security risk
by minimizing the attack surface.
You see how everything's starting to tie in here.
So system hardening, like I said a minute ago,
is basically the process of removing whatever
extra functionality may be in the system,
uninstalling any applications, anything like that,
to make the system as secure as possible
while still being useful.
Disable any unnecessary services for anything running
on a machine, for a server for example,
that you might not need on it.
Change any default passwords that are on a system.
And if you can, change what default accounts
are being used.
So maybe instead of admin, you use
a specifically named administrator account,
or something like that.
You don't leave it as something that is maybe a default that's
known across the internet.
Tighten down the firewalls as much
as you can on these systems.
These are all part of system hardening.
Now, I have another whole course on security hardening
if you want to dive more into hardening itself
and actually see some hands-on stuff for hardening Linux
and Windows systems as well.
I definitely recommend you check out that course, too.
But again, the goal here is to make your systems as secure
as you possibly can, while still maintaining
the functionality that is needed for your organization
to actually function.
What's the point of your organization existing
if it can't do what it needs to do to make money?
That's the point of the business.
So another method we can use to protect our infrastructure
and another thing we build in to our design
of our secure architecture is a concept
known as defense in depth.
This is a process of using multiple different layered
security controls, but they're all coordinated together.
They complement each other.
They don't necessarily reproduce the efforts of each other,
but they complement each other.
They're deployed in a coordinated manner.
This defense in depth strategy and concept
has really commonly been used for physical security
if you think about it.
If you think about the physical security of a secure business,
for example, you've got fences.
You have lighting.
You have locked doors.
You have cameras.
You have guards.
These are all different layers of security
that help protect the physical building itself.
And then all of this-- again, just another layer.
They all build on top of each other.
So typically, defense in depth-- you
address it from the perimeter in.
So you start off with the most publicly facing aspect
of your network and build the layers in as you go.
There's a lot of different types of controls and levels
of controls built in here.
So your firewall, for example, would be your perimeter level.
You have your firewall as your first line of defense.
Behind that, you may have an intrusion prevention system
to help look for things that the firewall may not necessarily
block.
And you can use network segmentation internally so
that, if an attacker does get in,
they're limited in scope to what they can see.
You also would have access controls and authentication
controls in there so that, if an account got compromised,
they would be limited into what they could get into as well.
You may have enterprise, or endpoint detection
and response, or antivirus on your endpoints as well,
another layer of the controls here.
You see where I'm going with this defense in depth.
As you get closer to the endpoint,
you're getting more granular controls,
more specific controls, and ones that will detect
different things as well.
It's all layered, these defense in depth.
And then we also have system hardening
can be a good defense in depth strategy as well.
Make the systems as secure as they possibly
can be while still keeping that functionality is a very
good layer to have in there.
And at the very end of it, you have your data
encrypted so that, even if an attacker made it
through all the rest of the layers of that defense
in depth model, by the time they're getting to the bottom,
by the time they're getting to the actual data,
that data is encrypted.
And without the key, it's useless to them.
So that's what's known as defense in depth.
So as we keep moving forward in this course,
we're going to get more specific in talking about various ways
to design the architecture.
We've gotten a lot of the basic terminology, principles,
and goals out of the way.
We're going to start getting more in-depth
on how to design it and what you need to keep in mind
when you're designing different areas
of your secure architecture.