-: So, we talked a lot about Defense in Depth,
but let's talk about how you can analyze
the Defense in Depth and see if it's actually
a good security architecture for you.
Now, when you analyze the architecture attackers
are always looking for a flaw in the security controls.
We've talked about this before.
You can four or five or six layers, but if all the flaws
line up perfectly that attacker's gonna get in.
And so, penetration testers are gonna act like
an attacker to find those flaws, gaps
and single points of failure.
You can use this as one method of finding those flaws,
but there's many other ways that you as a cyber security
professional, can do this.
When you're analyzing your security controls
always determine if they meet the given requirement
or stated goal.
Going back to the policy, what was management's intent?
We don't have to secure everything, but we have
to secure the important things and going back
to what those business goals are and what those
stated requirements are are gonna help you.
So for example, let's say we built a new website
and the management said that we need to make sure
all customer data was secure and you start going through
and you find out that some information was publicly
available, but it wasn't customer data, well,
if you met the intent you may be where you need to be.
So, we'll talk about that as we go through.
Now, reviewing the architectures there's really three
different viewpoints or lenses that you can look
at the architecture through.
There's the operational lens, the technical lens
and the logical lens.
Now, when we look at operationally we're gonna focus
on how it functions, how it performs its job
that it's supposed to accomplish.
Then we're gonna look at it technically
and technically is gonna focus on
the different technologies.
So for instance, in a website we may be talking
about TLS, version 1.2 implementation, its configurations,
its settings and all of that is used in the architecture
from a system or service level.
And finally, we'll look at it logically.
And logically kinda takes a step back from the technical
and looks at it how the interconnections of all
these systems, all the network flows and the data flows
that happen and it's less technical and it kinda
looks like a network diagram almost as you look
at the logical view of how these things are architected.
Looking at it from all three of these perspectives
allows you to see what the network is doing,
what the system is doing and is it meeting
its intended goal in a secure method.
Now, let's look at some common issues.
The first one is a single point of failure.
This one should just stick out at you like a sore thumb.
In this particular network that I drew up here,
what is the single point of failure?
It's the singular part of the system that could
cause the entire system to fail or if we're talking
about security, the desired security level to fail
if it's exploited.
Well, in our case, it's the router.
If you see in the center there's VP Router 0001.
Well, if that router goes down the entire network
is gonna crash because nobody can talk
to each other anymore.
This is a bad design.
It's not redundant and it's not well designed.
So, if I was looking at this network I would go back
to the person who gave it to me and say, hey,
we need to create a redundant network and start adding
an additional router and have them have a priority
and backup functionality and that would solve
this single point of failure.
Now, this is really easy because we're talking networks.
If you look at this from a security stack perspective,
that would be a much more challenging problem.
So you're gonna have to look at what single thing
could cause the network to fail.
The next one we wanna talk about is
data validation and trust.
This is a common issue, as well.
Data is commonly assumed to be valid and trustworthy
in the system, but it probably shouldn't be.
This can cause issues because you can trust input
from a user and they may put in a SQL inject, for instance.
This is all about trust and we don't ever wanna trust,
we wanna validate.
So, everything we do in our systems should be designed
to do integrity checking and validation of the input,
both on what's coming in and what we're giving back out
and we can do this with hashes and we can do this
through validation techniques in our secure coding.
Again, as you look through specific examples
in the real world and you look through a website,
for instance, and how it's coded, you need to make sure
that the data is being validated on input and that
the data as it's being stored is hashed and logged
so that then when we give it back out
we know that it's trustworthy data.
The next one we'll talk about is users.
Users are our largest concern for security failure
because they break our security all the time.
This can be just a simple mistake by the user
or it can be abuse.
Either way, the end result is the same.
Our security gets lessened.
And so how do we prevent this?
Well, we can use automated monitoring to detect errors.
We can do constraining the interfaces to only
what they're allowed.
So for instance, on my networks I don't allow my users
to get to the command prompt on Windows.
They don't have a need for it.
There's five or six programs they need.
We give them access to that and that's it.
We lock it down, right.
We can implement procedural checks and balances
so we can make sure that if we're creating an account
for instance, that system insurer one creates it,
system insurer two validates the permissions.
That's a check and balance system.
And finally, we can do user awareness training
like we just talked about in the past lesson
and it's really important to look at that
because it really does help and it is one of the most
cost benefit, one of the best cost benefit analysis
you're gonna see is when you give better user training.
Now, the next one we're gonna talk about
is authentication and authorization.
User credentials, passwords and permissions
can cause security failures.
And so, you have to make sure that those passwords
and credentials aren't being exploited.
How do you do this?
Well, if you're using single factor authentication
move to multi factor.
That would be things like a smart card and a PIN number.
That might be something like an RSA token and a PIN number
or a password.
That may be something like what Microsoft uses
or Google Authenticator uses where you can get
a changing code on your smart phone that has
to be inputted in addition to your password.
Those multi factor authentications really, really
do increase security.
Centralized account management is also a big one
and so is centralized privilege management.
By centralizing that instead of putting on each
and every host, you're less likely to have issues
and it's easier to update and change
when someone needs to change a password.
They don't have to go to every system individually,
they can do it once in the domain and push it across.
The next one is monitoring your privileged accounts
because administrators, yes, we trust them.
Otherwise, we wouldn't hire them, but you still
wanna verify because you never know when you're
gonna get a bad one, so you always wanna make sure
you're monitoring what your privileged users are doing
so you can go back and undo it
if they did something wrong.
And then finally again, user awareness training
because both your system administrators
and your users are vulnerable to issues like
giving away their credentials and giving away
their passwords, clicking on malware
and downloading it through spear phishing attacks
and other issues.
So, all of these are things that we wanna consider
and common issue when we look at the architecture.
Now, the next one we wanna talk about is how we do
an architecture review.
So, this is a step by step analysis of the organization's
security needs, starting with that first goal
and bringing it all the way down through the technical.
This begins with our design requirements and then
we look at the technical and logical diagrams
as we talk about those three viewpoints.
We're gonna identify issues and report them
to our organization per the processes of the organization.
That may be a formalized report.
It may be submitting a change ticket
in the change management system
or it may be submitting something into the continual
service improvement phase.
Either way, you wanna make sure that whatever you've
discovered that might be an issue gets put in
for funding and fielding so we can solve that
in the future.
Maintaining your secure architecture is difficult.
Threats change over time and systems become outdated.
So, the way we do this is three fold.
We're gonna conduct scheduled reviews.
Maybe that's every six months.
Maybe that's every year,
but we should be looking at these systems.
Maybe it's every five years.
I don't know.
It depends on your organization and your threshold for risk.
How often you wanna conduct them is up to you,
but you need to be looking at your systems,
your networks and your processes.
That's right, this isn't just a vulnerability scan.
We have to look at the processes, too.
Are our processes still working or are they
no longer valid?
Next we wanna look at continual improvement.
As I go through and look at these systems,
these networks and these processes,
what can be improved?
And by using that continual service improvement
we make these small incremental changes over time
that add up to big security in the long run.
And finally, the retirement of processes.
I might have a process that's just no longer valid.
Why is it still on the books?
Anything you don't need, you need to get rid of
because if it's there it's something that can be exploited.
So, anytime something's not relevant that process
needs to be retired and you can do that through
your change management process and that service
will be retired and that process can be retired.