[MUSIC PLAYING]
Before we dive too deep into secure architecture design,
it's a good idea to have a good understanding
some basic security principles that
are involved with designing a secure architecture and just
cybersecurity in general.
So the first one I want to talk about here
is going to be the CIA triad.
You may have heard about this before.
It is not the Central Intelligence Agency.
CIA, in this case, stands for Confidentiality, Integrity,
and Availability, three main ideas behind
cybersecurity in general.
So confidentiality is related to basically keeping
private data private.
If it's any sort of sensitive information
that should be private to an individual,
or a corporation, or anything like that,
confidentiality basically means, keep that data private.
This can be anything from things like PII or PHI;
for individuals, like driver's license numbers,
Social Security numbers, credit card numbers, health data;
or trade secrets for an organization,
or anything like that.
Any data that should be private--
confidentiality means it needs to stay private.
A lot of times, this can be accomplished
through things like encryption, access control methods.
This is a lot of times where authorization
and authentication systems come in.
You employ those systems to make sure
that, if users shouldn't have access to data,
they don't have access to the data.
So next, you have integrity in the CIA triad.
This is essentially meaning that your data
is free from any sort of unauthorized changes.
You haven't had a third party come in and modify this data
at all.
This can be accomplished through the use of things
like digital certificates or file hashes.
So when you create a file, you can generate a file hash
for it.
You send that file to somebody else
in addition to what the file hash should be.
They run their own hashing against it
using the same algorithm, and ideally
they should get the same hash result. And if they do,
they can be assured that file has not been
modified since you created it.
That's what data integrity is.
So you have confidentiality, integrity, and availability.
Availability means keeping systems online,
maintaining the timely and reliable-- those two
parts of it are very important-- timely and reliable access
to all systems.
So yes, availability is a big part of security.
If you have systems that are compromised, a lot of times
they will go down.
They will be unavailable to use.
So availability is a huge part of security.
Availability can be accomplished through things
like redundant systems, and then all of the security
controls you put in place are designed to maintain system
availability, to keep these systems online,
but also to ensure that data stays confidential
and that data is not modified through unauthorized means, so
all the confidentiality, integrity, and availability.
So let's go over some other general cybersecurity
principles that you should be aware of when we're
talking about a secure architecture
and specifically designing a secure architecture.
It's the concept known as Trust but Verify.
This applies to all different aspects of cybersecurities.
This is essentially meaning you can trust what a system says,
or what a person says, or a vendor
says, or anything like that.
But you want to verify that information
and what you are seeing is accurate.
You want to check all of the controls,
check all of the settings, make sure
they should be where they are, or they are where they
should be, either one of those.
Everything should be set the way that it
is designed to be set as far as settings and things like that.
You trust that it's accurate, but you also verify
that it is accurate as well--
Trust but Verify.
You also have a concept in cybersecurity
known as Zero Trust.
This kind of ties in with Trust but Verify.
This is a model where basically nothing is
trusted until it is verified.
So kind of as the name implies, Zero Trust,
there is no trust in any systems,
or data, or anything like that until it is verified.
"Defense in Depth" is a very common term
you'll hear when you're setting up cybersecurity controls.
Defense in Depth is essentially the practice
of putting multiple layers of security controls in place.
The design here is that you have a system you're
trying to protect, but you have various different layers
of cybersecurity controls that are working
to protect that system on a network level, at a file level,
at an access control level, any of those like that.
We'll go into Defense in Depth a lot more in depth--
haha-- in a later video as well.
But it's basically the use of overlapping systems,
not necessarily identical systems, but overlapping
systems that work to provide this defensive layer
to a system, or a set of systems,
or a network, or anything like that,
to help give it more protection.
And one good practice in here is you want to try, if you can
and if it's practical, to use different vendors
for these different layers.
That gives you a kind of a different viewpoint
and a different approach to security
than potentially using the same vendor.
Now, using the same vendor does have its benefits as well.
You have a lot of interoperability
between controls if you use the same vendor there,
so it's just something to keep in mind.
Another concept should be aware of but you should really
never use if you can avoid it is security through obscurity.
This is the practice of setting up security and securing assets
by making things difficult to detect.
Basically, you're hiding things in an effort
to make them secure.
A good example of this is a hidden SSID
on a wireless network.
It's trivial for anybody to find that through a network scan,
to find a hidden wireless network.
A good example of this is using nondefault ports
for a public-access website, say.
Like, for example, instead of using port 80,
you use port 81, or port 8080.
You're attempting to hide the assets
through use of different protocols, or hidden networks,
or anything like that.
But it's extremely trivial to bypass these controls.
So you're not really securing anything.
You're just kind of hiding them.
That's what's known as security through obscurity.
And you have assets, inventory management, inventory control.
This is an important part of cybersecurity and, really,
any sort of IT infrastructure.
You can't properly secure your assets,
you can't properly secure your environment
if you don't know what's in your environment.
This is where inventory control, asset management
comes into play.
So you can know what's in your network.
You can know the details about it, operating system, vendors,
software levels all kinds of information,
so you can better know how to properly secure it.
So let's talk about some various security techniques.
There's a common phrase known as minimizing the attack surface.
This is a whole set--
not even really a set of procedures, but basically
just a concept, where you're trying
to reduce what is available for an attacker to compromise,
whether this is removing unnecessary services, closing
open ports that don't need to be used or don't need to be open,
or anything like that on any sort of device or system.
Basically, your goal here is to give the attackers less area,
less things that they can attempt to compromise.
That's what's known as minimizing the attack surface.
A concept known as secure defaults--
this is essentially the practice of deploying systems
with Secure by Default, when you set up
new systems, new devices that are configured
in a very secured manner prior to being deployed.
This is also known as hardening, server hardening,
and things like that.
You can use server images to properly secure servers.
So you create an image for a server,
especially for a virtualized environment,
configure the security on that, and use that image
to deploy more systems.
Some examples of that is not using default passwords
on systems, changing that, disabling ports
that aren't used, and disabling and uninstalling
services that aren't needed.
Secure defaults really often means
that systems may start with a lot more security in mind
than they do with user friendliness and functionality
in mind.
So secure defaults is often a fairly drastic step
that you usually--
you take a few steps back from that as you deploy the system
and figure out what functionality is really needed.
We'll go into more detail in on that as well.
But keep in mind, secure defaults a lot of times
is the system's going to be more secure but less usable.
So just keep that in mind.
You have a concept known as privacy by design.
This is a pretty self-explanatory one,
basically says, private data should be secured at all times.
This is privacy should be built into systems, to applications,
to keep that private data private.
This is the confidentiality portion of the CIA triad.
You have fail secure.
I know we're just going through a bunch of terms.
That's what we're introducing you to some of these terms
and some of the basics here.
So fail secure-- this is a concept that, if and when
a system fails, that it should fail in a predictable manner.
When it fails, it shouldn't increase the concerns
you have about the security.
Systems should be able to fail in a very predictable
and a non-compromising, or uncompromising, behavior.
You should know what's going to happen when a system fails.
And this isn't just when a system fails, but this
is when something may not be working 100% properly,
not a complete failure.
Some examples of this--
say you have a web browser that is set to refuse connections,
refuse to pull up sites.
If a certificate has errors, if it can't verify a certificate
properly, it'll refuse to pull up
the website instead of just giving a warning
that a user can bypass.
That's what's known as fail secure.
Another example of that is if you
have a firewall that just unexpectedly powers
off, or reboots, or anything like that, that it fails
in a way that blocks all traffic until an administrator
and analyst can go in there and verify the integrity of it.
Yes, it could have been rebooted from any number of errors.
But with security, a lot of times
it may be a better idea to be safer, in that case,
to lose a bit of functionality for a short amount of time
until you can verify that your systems are still secure.
That's what's known as fail secure.
And some authentication and authorization kind of topics
here-- there's one known as least privilege.
This is the practice of only granting the access,
only giving users access that they need in order to perform
their job and nothing more.
You only give them what they need
so that they can do their job.
So all users don't need to be administrators
on their computer.
They don't need administrative access in order
to actually do their job.
That's what least privilege is.
You give them the least amount of privilege
for what they need to do their job.
You have separation of duties here as well.
This is where you start to introduce roles
into authorization, and we'll get
into a bunch of role-based access controls later.
But this is where you begin to introduce these roles.
So basically, you give users access based
on what their job role is.
This ties directly into lease privilege as well.
So you're only giving them access to what they need,
but you're doing it based on what their job
role is, their job title, and what
their responsibilities are.
So you don't give users access to systems
that they don't have any business need to access.
And you have Role-Based Access Control, or RBAC.
This is where you create those roles, you create those groups.
Instead of signing permissions directly to users,
you assign permissions to these groups.
And these groups are basically tie into the roles.
So then you assign permissions to the groups,
and then you assign the users to those groups or roles,
which makes it a lot easier to manage that authorization and--
not really authentication, but definitely authorization,
and to help prevent what's known as authorization creep.
This is what happens when you grant users
more and more access over time without removing
any of their old access.
A lot of times, this happens if employees transfer departments,
or get a promotion, or any other change in their job role,
where they don't need access to their old systems anymore.
But they still have access to them.
That's what's known as authorization creep.
What they have authorization to access--
it just creeps up and up and up over time.
Best way to do this is to make sure you're-- or prevent this,
really, is to make sure that old access is being removed and new
access is being added as needed.
And role-based access will definitely significantly help
that as well.
And I'll go into role-based access
later on in this course as well.
But this video was basically just
to get you familiar with a lot of these basic terms
that you're going to hear over and over throughout the scope
and time frame of this course as well.