Now before we start diving too deep into the actual processes
behind designing our infrastructure,
let's talk about a few more key things
to be aware of when it comes to secure architecture.
Basically, it's just some of the general principles
that secure architecture is based off of.
The first one I want to talk about a little more detail
is one called zero trust.
There's a couple of different concepts behind zero trust
Here.
First of all, attacks can really come from anywhere
on the network.
We're not talking about attacks just coming in
from the internet perimeter.
Attacks can also originate from a workstation on a computer
from an infected USB drive.
Or maybe you have a malicious insider.
Or you have a user that's accidentally installed
something they shouldn't have.
There's many different areas and many different places
an attack can actually originate.
So that's one thing to keep in mind when
it comes to zero trust.
The other thing is, you may have some attackers that
are a little more persistent and more advanced,
something like an APT that are going to take their time.
They may spend days, weeks, months even, on your network,
inactive.
They may get their foothold and then just wait.
So a couple different things to keep in mind here.
Also, again, you have the malicious insiders
or careless insiders.
Keep that in mind as well.
It's not just people who have malicious intent, employees
that may have malicious intent.
It's employees whom just may not know any better.
They may accidentally do something.
They may do something because they weren't aware
that what they were doing was going to create issues.
So the reason I bring up these three things
is zero trust is all about assuming everything
in your network, all entities on the environment
are malicious unless proven otherwise.
You essentially have zero trust in anything
until it is proven otherwise.
This is similar to trust, but verify,
but there's no trust in this part.
There is zero trust.
Now, a full zero trust deployment or model,
it's nearly impossible to implement.
To do a full implementation of zero trust,
it's nearly impossible.
Your entire infrastructure, your network, your environment,
everything would be way to lock down
to really get anything done.
You would have full security and very
little usability and manageability
of the environment.
You wouldn't be able to do anything in the environment
because it was so secure.
You know, equate that to if you're building a house,
but you want it to be the most secure house in the world.
So you build the entire thing out
of thick steel with no windows or doors.
Well, you can't use that house because you
can't get in or out.
That's the equivalent of a full zero trust model.
Everything's way to lock down.
However, you can do a targeted approach
to zero trust, where you might choose to.
In a lot of places, you might do this.
A lot of your specific areas might be targeted,
and you may have specific systems you might
target for a zero trust model.
Usually, these may be some of your more critical systems,
systems that may work with industrial control
systems or that hold highly confidential or private
information.
Perhaps, some of your more public-facing systems that
may interact with those confidential systems as well.
That's a lot of the places where you
might want to consider implementing a zero trust
model.
But, again, a full zero trust implementation
is pretty impractical just because you become so locked
down and so worried about security
that you have no real usability.
So let's compare that to a trust but verify model.
You still may trust things in your environment,
but you still go in and verify the settings are
what they should be, that the systems are behaving like they
should be, like everything is working the way that you trust
it is working.
But you're going in and verifying all of that.
That is what trust but verify is.
So it's a lighter version of zero trust.
You're actually have some implicit trust in there.
A lot of times, this is implemented alongside a zero
trust model with it somehow.
But it's also very frequently used, completely independently
of zero trust.
You do not have to use these two models together.
Now, a lot of the key parts of a trust but verify model
are making sure you're constantly
auditing these systems because how else are you going
to verify that they are behaving and working and set in the way
they should be.
You've got to have that auditing set up,
and you have to have specific processes and procedures tied
into that auditing that dictate how often the audits are
performed, what specifically you're looking for,
things like that.
You have to have these auditing systems.
You have to go in and check these systems
and check these settings, so that you can verify.
You have to do that verification part of the trust but verify,
and that's where auditing comes in.
You got to have processes designed,
and that can help build that program and help facilitate
that, so that you have everything documented carefully
as what needs to happen as part of this verification process.
Now, a lot of these processes should
place the proper emphasis on the different tiers
of systems you may have.
Example of that is your highest tier.
Your tier one systems should have, out of all these,
maybe they have the least amount of trust
and the most amount of verification.
That's one option.
Or you can have more frequent auditing on your higher tier
systems than you do on your lower tier systems.
Regardless of how you actually implement that,
your processes really should keep
those tiers of systems in mind when
the processes are designed.
And just like so many other things in cybersecurity,
automation will make this process much simpler,
and baselines are really key here.
You need to know what you're verifying against.
Yes, you have what it should be, but these baselines
will make it much easier, especially if you're
trying to automate the process.
You need those baselines to have that automation be
able to compare against something.
So that's the big differences is between zero trust and trust
but verify.
Among we talked about in one of the intro
videos is security through obscurity.
This is effectively using secrecy
as your primary method of security,
which is not a good idea.
Because this does not give you any real security at all.
All it's going to do is, maybe, slow down the attackers, maybe.
It's not even a guarantee that that's going to do that.
Depending on what you're hiding, the attackers
will have no impact on the attackers.
This is not something you should ever
rely on as a standalone option for security controls.
Security through obscurity is not a good control on its own.
Used with other security controls
more than our actual security controls,
the obscurity part can play in and can be
a little bit more successful.
But do not ever rely on security through obscurity
as a real cybersecurity control.
There's some examples of what I mean by this.
Hidden wireless SSIDs.
That's trivial for anyone to detect those wireless networks
if there's any devices ever connecting to it.
It's trivial to do.
You may want to do that at home if you don't want your neighbor
jumping on your wireless.
But in an enterprise environment,
if you're actually trying to secure your environment,
hiding the wireless SSIDs by itself
does not give you any real security.
Again, tying it in with other security controls,
hiding the SSID may give you a little bump
in your security, maybe, a little bit.
But by itself, it does really nothing at all.
Another one is using non-standard ports
on public sites if those public sites don't really
have any business being public.
For example, if you have an internal system
that some people need to access from outside the network,
but you just make it available through the firewall
on a different port.
It's never used-- the general public is not ever
going to test it or anything like that, that Is
what I mean by this one here.
An attacker is easily going to detect that
through a simple port scan.
Yeah, your regular internet users
might not stumble across this site,
but an attacker will easily detect this
through a regular port scan, regardless
of what port you use.
This is an example of security through obscurity.
You're just trying to hide the fact that the site is really
publicly available.
Another one is you have sensitive data.
But instead of encrypting it, you encode it.
Encoding is easily reversible if you
know what coding system was used,
if you know what algorithm or anything was
used to encode the data.
Encryption is the one that is non-reversible
if you don't have the proper key.
That's the difference between encryption and encoding.
If you have sensitive data that needs to be protected,
you need to encrypt that data, not encoding it.
Encoding it, yes, it will obfuscate the data.
But again, that's security through obscurity.
Anyone can easily reverse that.
So another way to think of security through obscurity
is, you have your front door in your house
that you lock every day, but you have that key under the mat.
Everyone knows to look for the key under the mat.
You're protecting your house through the secret
that the key is hidden under the mat, but it's trivial to find,
and it's trivial to bypass.
It's not real security.
Now, like anything else in cyber security
and really, in IT, in general, inventory management,
asset management is key.
This is a critical piece of any security program.
Why?
It's impossible to really secure your environment
and secure your assets if you don't know they exist.
If you don't know what's in your environment,
how are you going to secure it?
Now a proper asset management program
should really be built on multiple processes that
are handled by various areas in the environment.
Procurement should be the department
that handles your initial purchasing, and licensing,
and logs that information in the asset management system.
Your IT departments, they'll be documenting
the location of these assets, how they're used,
any infrastructure information like IP addresses,
host names, switch ports, depending
on what information is need.
But your IT department documents that
into your asset management.
Your cybersecurity department is going
to document what controls and countermeasures may be deployed
on these systems, a vulnerability status, patch
status of these systems, all kinds of things like that.
And you can see where all different departments all
have a hand in this asset management system and program.
Really, at a minimum, anything that's
connected to your network should be
recorded in an inventory management or an asset
management system.
If it's plugged into your network,
it should be recorded and inventoried.
Now, a proper asset management system,
knowing what's on your not your network directly
ties in to your vulnerability management program.
And I say directly ties in.
It is important for your vulnerability management
program.
But oftentimes, depending on the systems,
there are actual direct API calls into each other systems.
So your vulnerability management commonly
used as an asset management system and inventory management
system to know what it needs to scan for a vulnerability scan.
Your patch management system.
You need to know what systems you have deployed,
so you can know what patches need to be installed
and where they need to be installed.
Obviously, your risk assessment programs.
you need to know what your systems are so you can identify
what risks they might pose to the organization, what
the threats are against it, and be able to protect it.
All of these tie into a proper asset management program.
And then, of course, audits.
Audits are always going to ask, depending
on the audit, of course, what type of inventory management
you're using.
They're going to want an example out of that system,
depending on the audit.
Even if they don't ask for the information directly from it,
having a proper inventory and an up-to-date
maintained inventory will make responding to general audits
much easier as well.
So just a few other key points and principles
of secure architecture before we really
start diving into why secure architecture is important
and how we start designing and completing this process.