[INTRO MUSIC]
So now we're going to start talking
about the secure infrastructure portion of creating
our architecture design.
So to start off with, let's talk about what may actually
be in our infrastructure.
What is our infrastructure made up of?
Well, first of all, we're going to have our servers.
And there's servers for all kinds of purposes.
You can have multi-use servers that
have a lot of things installed on them, multiple purposes
for that individual server.
But you also going to have dedicated
servers for specific purposes.
You may have your Active Directory servers,
which handle your authentication and authorization
services for a Windows network.
You have file services, which are where all of your files
will be stored for access across the network.
You got web servers, database servers, application servers.
There's all kinds of numbers of different types of servers
that you'll have in your infrastructure.
And it's important to know what each one does
and how the applications or services on them
work so you can be familiar with proper ways and methods
to actually secure them.
And you're going to have workstations on your network.
This is going to be Windows, Linux, Mac, any other operating
system you may have.
Your workstations are going to make up
the bulk of your environment for the most part,
depending on the size and type of organization.
But most of the time your workstations
make up the bulk of your actual infrastructure,
with servers taking the number two path or, potentially,
your network devices.
Now, network devices-- the most of what
you're going to have for network devices
is probably going to be switches.
And these can be layer 2 or layer 3
switches, depending on your organization
and how your network is set up.
Your network devices are part of your infrastructure
and should be part of your overall secure design
when you're building out this infrastructure.
Things like your firewalls-- where do you have them?
How are they positioned?
How are they configured?
How many do you have?
What purposes are they serving?
And you have your routers and your switches
also, which are basically just your core network
infrastructure.
Configuration on those is going to really depend
on the complexity of your network
and how it's really going to be laid out.
You're also going to have IoT devices on your network
as part of your infrastructure, whether you like it or not.
Now, this can vary in your organization,
really, depending on what your organization does
and how everything is built, honestly.
So you may have a lot of IoT devices.
You may only have a couple.
But this could be things like thermostats.
Those can be considered IoT devices,
any sort of media devices like an Apple TV
or a Roku or a Chromecast or any other number of those types
of media streaming devices.
You could have surveillance cameras, doorbells.
Any of those types of devices can be considered IoT devices.
And you need to plan your infrastructure
appropriately for those.
Most of the time for IoT devices,
your best solution for that is network segmentation.
Get those devices on their own network
that don't talk to your enterprise infrastructure
in any way unless they have a specific reason.
But, again, isolation and segmentation's
your best bet for your IoT devices.
Can't forget cloud-- may be a part of your infrastructure.
So many places are using cloud services these days.
Now, whether you're using cloud for infrastructure
as a service, platform as a service,
however you're using cloud--
software as a service, whatever you're using your cloud
infrastructure for, know that cloud
needs to be a consideration when you're designing
your secure architecture and when you're
planning all of this out.
Now, how you're using cloud, just
like all the rest of the list, is going
to depend on your organization.
Maybe you're using cloud for your entire Active Directory
infrastructure.
Maybe you're usually using Azure AD for your Active Directory
instead of using an on premise Active Directory.
Maybe you're using cloud for all of your file
shares or applications or anything like that.
So, really, depending on how it's
being used in your infrastructure
will determine what place it takes
in your secure architecture design.
You may have virtualization technology.
This could be virtualized servers,
virtualized desktop, even virtualized network setups.
Any of that stuff can be virtualized.
And what servers very frequently is you're
seeing it also more frequently with desktops and network
devices as well.
So keep in mind, if your infrastructure--
if your organization is using virtualization,
it needs to be part of that secure design.
So, really, each of these parts of our infrastructure
is going to require various different steps to properly
secure and to properly plan out how they're going to fit
into the secure architecture.
However, the basic guidelines for all of them
can remain the same.
We'll get into a couple of those basics here in a minute.
But things that apply to everything
regardless of what it is is going
to mean no default passwords.
Change those default passwords and usernames if you can.
Disable services and ports that don't need to be open.
Basic things that apply to any device to get it more secure,
that needs to be part of your planning.
And your end goal here with all of this
is to protect your company's data,
protect the company's assets and information, including
any private information that may belong to users or customers
and employees.
All of that while ensuring continued operation of all
of the business processes that are
critical to the organization.
This all ties back into our CIA triad.
We're protecting the confidentiality of all the data
that needs to remain confident, making sure
the integrity of all the systems and data is maintained.
And make sure it all stays highly available,
as it needs to be with that final A in the CIA triad.
So let's talk about some of the basics
for securing and, most importantly, planning
a secure architecture.
Before you start properly securing any of your systems,
you've got to do some fairly in-depth planning to figure out
what's going to be involved, where everything's
going to be located, what the layout is going to look like,
how everything is going to tie together and talk
to each other.
Now, you can do--
you can set up secure systems.
And you can set up security without any planning.
You can do it ad hoc.
It's not recommended.
That's why I say, and I have here bolded on the screen,
before anything can be properly secured,
planning is going to be required.
Ideally, you want to use your defense in depth strategy.
And we talked about that in another video.
Basically, you want to layer all of those security
controls and countermeasures and systems to fill as many gaps
to hide--
or not hide, but to eliminate as many attack vectors
and minimize that attack surface as well.
And the layering helps provide redundancy
in some of your security controls
as well, so not just filling gaps but kind of overlapping.
That's your whole defense in depth strategy.
Proper network segmentation-- that's
something that needs to be planned out.
You can't just start segmenting up your network
without planning.
I've seen organizations try it before.
It does not go well at all.
So proper network segmentation needs to be thoroughly planned,
definitely planned out with your network engineers,
your security teams, anybody who needs to be involved there.
But definitely network security.
And anybody else in IT needs to be involved.
But, essentially, you want to split up your network
into different sections.
And those sections are going to be based on the purpose
they serve and what sort of access rights
are appropriate for those sections.
For example, you may have a specific network set up just
for your finance servers or your database servers
or certain application servers or anything like that.
You may have separate VLANs and network
segmentation for different workstations as well.
You definitely want to have your IoT devices
segmented off into their own segmented network using
your VLANs or whatever technology and processes you
want to use for network segmentation, just
know it is extremely important for a secure network
and a secure design, it needs a lot of planning.
You also want to have a good process and infrastructure set
up for your identity and access management or IAM.
This allows you to have those proper controls
for your authentication and your authorization
to make sure users can properly authenticate to your network.
Unauthorized users can't get access to your network.
But authorized users have access to only
what they need access to.
This is where the least privilege concept comes in
and your separation of duties, making sure
that people only have access to what they need in order
to do their job and that roles are properly separated out
and one person doesn't have all of the rights to do everything.
You separate those duties out and those roles out
based on duties so you can attempt
to avoid authorization creep.
RBAC, role based access control, makes that a lot easier.
If you're assigning roles instead of permissions
to individual users, it makes it easier to roll back.
Roll back, see what I did there.
It makes it easier to remove permissions as people change
jobs and change positions in the company
so that you can avoid the unnecessary authorization
creep.
And then documentation.
Documentation is-- you heard me say it many times.
Documentation's key in anything cybersecurity related,
including when you're designing a secure architecture,
especially when you're designing a secure architecture.
It's got to be well documented.
All of your security infrastructure,
all of your controls need to be thoroughly documented.
Where they are, what they do, how they're
configured, their purpose--
all of that needs to be well documented in addition
to any policies and procedures that apply to anything
in your infrastructure.
Those need to be well documented as well.
Change management process makes this a lot easier
but also involves a lot more documentation as well.
This is a process through which you track the changes
in your environment or proposed changes in your environment.
And have a way to approve them and review them
as part of an overall team and organization.
So I want to call out a couple specific techniques
you can use that will help secure infrastructure.
One of the first of all is going to be encryption,
properly encrypting data.
This is going to be part of an overall defense in depth
strategy, usually at the more interior levels
of your network, where your data actually lives.
This is what's going to be encrypted.
Combine it with access controls and permissions
as well because you don't want to rely on just one control.
You don't want to rely on just the encryption
to protect your data.
You want to make sure permissions
are set up properly.
You want to make sure all the access
controls are set up properly.
You want to layer that defense there for your defense
in depth strategies.
Now, some best practices when it comes to encryption.
Mobile devices-- encrypt them.
If they can easily be picked up and carried out
of your physical office space, like a phone or a laptop
or anything like that, a tablet, anything--
it needs to be encrypted.
Whether or not it's really going to have any sensitive data
on it or not, if it's going to connect into your network,
it has the potential to get data on it.
Regardless of what the intent or purpose
is, still has that potential.
You want to make sure that data is encrypted just in case
it may get on there.
Any sensitive data you have on file shares, databases,
application servers, workstations for that matter
should all be encrypted while at rest, which is basically
when the data is just sitting in its database or file structure
or wherever it's sitting, and also in transit,
when it's being sent to and from computers, servers,
file servers, anything like that.
That's what's known as being encrypted at rest
and in transit.
This applies, again-- databases, file servers,
email databases as well.
A lot of those are going to be encrypted by default.
But it's something you want to trust but verify.
Another important concept we've discussed.
A lot of your desktops could be encrypted as well,
depending on what sort of information is on them.
Now, with a Windows environment, this is very easy to do.
You can control these settings through Group Policy and Active
Directory and have your Windows desktops automatically
encrypted using BitLocker.
So it becomes very easy.
Any configuration records that you
may have for any of your systems,
especially your network devices if you're
using-- certain devices let you easily export the configuration
as, basically, text entries.
You want to make sure those are properly
encrypted so nobody can accidentally
get there or maliciously get their hands on how your network
infrastructure is configured because that can give
an attacker valuable information that they
need to be able to traverse your network,
where they shouldn't be able to.
So if you have these configuration files backed up
or saved anywhere, you want to make sure those are properly
encrypted also.
And that's not just network equipment.
That's any kind of saved configuration files
that have any sort of sensitive or critical proprietary
or passwords.
Any configuration that could make
it easier for an attacker to get in should be properly secured.
Backups definitely need to be encrypted.
Any offline backups should be encrypted so that an attacker
can't just get those backups.
And they stole your data just from stealing your backup
instead of having to actually get into your network
and into the more secure encrypted locations
that the data is encrypted on your file servers
or in your database servers.
The backups should be encrypted as well.
There's a lot of different technologies
that are available for encryption.
I mentioned BitLocker for a Windows environment.
Mac has one called FileVault as well.
So there's many.
There's also a lot of third party products
you can use for encryption.
I just mentioned two that are built into operating systems.
So whatever technology you're using for encryption,
just know that it is an important part
of a proper defensive--
especially a layered defense in depth strategy for security.
Another one I want to call out specifically
is going to be email security.
There's several different components of email security
that your email administrators should be aware of.
And they should be, honestly, probably
the ones configuring these.
But it's things you should be aware of as well
when you're designing a secure architecture because these are
things that can be set up from the ground
up when you're configuring an email environment
and also need to be maintained.
And security personnel should be aware of them
and know what they mean and know how they work.
First, what I want to talk about is SPF.
This stands for sender policy framework.
This is a strategy that's been set up that attempts to prevent
and block email spoofing, basically
an attacker essentially faking where
an email address comes from.
I used to always tell a bunch of users
when I was kind of doing security awareness
training internally in companies,
it's as easy to spoof an email address
as it is to write a fake return address on an envelope, when
you're actually sending something in the mail,
like snail mail, because people still do that.
It happens.
So it's that easy to spoof an email address.
And SPF is an attempt to prevent that
from happening or at least making
it a lot harder to accomplish.
Essentially, SPF is a DNS entry in public DNS
that specifies which host--
which sending email hosts are allowed to send email
as a given domain.
So if you have xyz.com, you would specify in a public DNS
record what IPs or what servers are allowed
to send email as xyz.com.
If other receiving servers receive email
from somewhere else or another IP that's
not in that DNS record, it is going
to flag it as having failed that SPF verification and will
very likely be marked as a malicious email.
Another one that you can use to help boost your email security
is one known as DKIM or domain keys identified mail.
This is process-designed to help validate
where emails come from, validate the origin
and integrity of the messages.
It does that by the sending email servers digitally signing
the messages as their center.
This is not email encryption.
This is a digital signature that allows you to do integrity
checking and non-repudiation.
You can validate, yes, this did come from this.
And DKIM also works with a public DNS record
to verify public private keys pairs.
So the sending email server signs every outbound email
with that digital certificate, that digital signature.
So the receiving email server can look at that,
verify it against the public key, which
is going to be a DNS record, and verifies,
yes, this email did come from this location.
And, no, it was not modified in transit.
One third one I want to talk about is one known as DMARC--
long one-- domain-based message authentication
reporting and conformance.
What does that actually mean?
Well, this is a kind of a combination.
It combines your SPF and your DKIM for all the email traffic
and instructs sending--
or, excuse me, receiving servers of what
should happen if an email fails SPF or a DKIM record
does not match properly.
You set up DMARC instructions on your sending servers
so that when receiving servers check that, they look at that
and go, OK, so this message failed SPF.
This is what I should do with this message
or this DKIM signing did not match.
This is what I should do with this.
It allows the sending servers to supply those instructions
and also adds some reporting features for SPF and DKIM
so that when a receiving server gets an email,
if something doesn't match up, it can actually report that
back to the domain owner, not necessarily
the sending server but the domain owner,
so they can potentially see if other systems are attempting
to spoof their domain.
And then data privacy.
Data privacy-- this is not one of the features of email
security.
But email is not a secure communication method.
Email is sent in clear text unless it
is specifically encrypted.
Now, a lot of email systems are starting to encrypt by default.
But as a protocol, email was never
designed with security or encryption or privacy in mind.
So if you have sensitive data that you're
sending through email, unless you
are verifying that it is encrypted when it is sent
or before it is sent, your message
is being sent in clear text.
When you email someone your Social Security
number or your credit card number or anything like that,
if you're not making sure the email is
encrypted when it's sent, assume it is sent in clear text.
Email is not by default a secure communication method.
So talking about security because that's
what we talk about in these courses,
let's talk about fail secure.
This is very closely related to when
we talked about previously secure defaults.
But instead of talking about new configurations,
we're talking about, what should happen when something fails?
What happens when a device fails or goes offline or isn't
behaving as expected?
When a failure occurs, devices should
behave in a very secure and predictable manner.
There's many different ways to interpret this.
So the best way I can really kind of relay this
is to give you a couple of examples.
Number one, let's say if you have a firewall reboots
or power cycle.
And it wasn't expected.
Obviously, if you're doing maintenance on it,
it's expected.
But if it wasn't expected, an example of failing secure
would be when that firewall unexpectedly reboots.
All traffic is blocked until an administrator or a security
analyst can get in there and analyze
it to make sure that the reboot was not
due to malicious behavior.
Once that has been verified, then the traffic
is unlocked and behaves as normal.
Yes, this can cause an interruption
to service, interruption to network connectivity.
But a lot of times a brief interruption like that--
keep in mind, it was already interrupted
if the device rebooted.
A slightly longer interruption is
often preferable to an undetected breach.
So if you're worried about that, which you
should be worried about that--
but you never know if an unexpected reboot is just
a configuration error, an overheated piece of equipment,
just a software fault or something like that,
or if it's due to malicious behavior
and malicious activity.
So failing secure would be when that fails.
It locks down until it's been able to be verified.
Another example of that is if you have your antivirus or EDR
software on your endpoint or file
server, anything like that.
If it encounters any kind of critical errors
and is unable to continue functioning and continue
scanning, then it locks down the system
until it can be verified and restarted
or wherever else needs to be done
to it until that system can be checked
to ensure that failure of the EDR software
was not due to malicious reasons.
It's locked down until that verification happens.
Another example of fail secure.
So you have websites that you visit often
that usually are protected with certificates.
If you have websites that have unverified certificates or--
whatever there's a problem with the certificate,
whether it's expired or the name doesn't match
or it's not issued by a trusted CA or anything like that.
An example of fail secure is when
the browser encounters that, the connection is blocked.
The connection is refused.
And the user cannot overwrite it.
That is an example of failing secure.
Normally, when that happens, the user
is prevented with an option.
Hey, here's a warning.
The certificate doesn't match.
Do you want to continue anyway?
Failing secure would be not allowing the user to continue.
So a few good examples there of what fails secure really
is and how it is kind of put into place as far as designing
a secure infrastructure and a secure architecture as well.
So we went over a lot of the things
you can do-- some of the basics you
can do for secure infrastructure and how you can integrate
a lot of that into your planning and why
it's so important to thoroughly plan everything out
before you start implementing.