- Welcome to Lesson 9, Deep Dive Quiz.
Now, Lesson 9 was all about explaining
the purpose of mitigation techniques
that we use to secure the enterprise.
And we looked at two lessons:
9.1, Secure Design Principles
and Lesson 9.2, Segmentation.
So now we're gonna do five questions together.
I hope you have a piece of paper and a pen or pencil.
'cause just like before,
I want you to put me on pause,
try to answer the question the best you can, right?
Then come on back and hear the explanation.
So let's start our quiz.
"Devices in the security zone connect to both trusted
and untrusted environments."
Is this a screen subnet, a honeynet,
an air-gapped network, or an enclave?
So devices in the security zone
connect to both untrusted and trusted environments.
Are we talking about a screened subnet,
a honeynet, an air-gapped zone,
or an enclave?
What do you like?
Well, I'm gonna choose a screened subnet.
A screened subnet is going to connect
to both the trusted and untrusted.
And as I talked about in the lesson,
we used to refer to it as a DMZ, right?
A honeynet is just a network of our honeypots.
An air-gapped network
is never going to connect to an untrusted network
or to any any network or device
that connects to an untrusted network.
And an enclave network is going to be a trusted network
within our trusted network.
So I'm going with screen subnet, let's check it out.
And that's correct.
Question two.
"System architects are discussing secure design principles
including one, multiple layers of controls,
two, permission-based access controls,
and three, privilege access management.
Which principle in the list below there
is not included in their discussion?"
Least functionality, default deny,
zero trust,
or defense-in-depth.
So they're talking about multiple layers of control,
they're talking about permission-based access,
and they're talking about privileged access management.
So what's not really included?
Well, let's go through it.
So multiple layers of control.
Well, that would be defense-in-depth,
they're talking about that.
Permission-based access control,
that's gonna be default deny,
where there is no access until you get permission.
And privilege access management,
that is one of the supporting things that we do
for a zero-trust environment.
What we don't see anything here
is about least functionality.
Least functionality is ensuring
that there's no unnecessary open ports
or protocols or services or applications
in a device, right?
We're trying to have a small footprint, right?
And as small as attack surface as possible.
So what we don't see here would be least functionality.
Do you agree?
Let's check it out.
And that's correct.
All right. Question three.
"Micro-segmentation allows for the implementation
of zero-trust protect surface environments.
Which statement is not true?"
Not, again, that important word,
not true about zero-trust protect surfaces.
That means three of these statements are true
and one is not.
It supports standing privilege.
It's always knowable.
It's orders of magnitude smaller
than the enterprise attack surface,
and it incorporates the network's most critical DAAS.
So which statement is not true
about a zero-trust protect surface?
But let's start on the bottom.
It does incorporate the network's most critical DAAS.
It obviously, a protect surface obviously
is always gonna be magnitudes smaller
than the enterprise attack surface.
It's always knowable, right?
Because it's your most valuable assets.
Ah, here's what it doesn't do.
It doesn't support standing privilege.
What is standing privilege?
Standing privilege means that you have always on access.
If you are a network administrator
and you have full admin rights,
well, that means you always, always
have those full admin rights all the time, right?
That would be standing privilege.
In a zero-trust environment, right,
it's really the opposite of standing privilege, right?
We're not giving you standing privilege.
Matter of fact,
you are going to be required to reauthenticate
over and over and over again
and only be given the rights and permissions you need
for a limited period of time.
So what is not true is that it supports standing privilege.
Do you like that one?
Okay.
And that's correct.
Let's go on to question four.
This is a matching one,
so you're definitely gonna need to put me on pause
while you work through this.
We're gonna match the security principles
and the discussions.
Least functionality, survivability,
least privilege, and default deny.
Now, be careful here 'cause it's really easy
to confuse least functionality and least privilege.
On the right-hand side, we have that the system property
that access is not allowed unless specifically specified.
Removing unnecessary services, protocols,
applications, et cetera, from an object,
or assigning minimal rights and permissions to a subject.
So put me on pause, match them up, then come on back.
All right, let's start with the first one,
a system property.
Well, the one in the list here would be survivability.
Survivability is a system property.
Access not allowed unless specifically specified.
Ah, that sounds a lot like a default deny posture.
There's no access allowed until we specifically allow it.
All right, now we're left with least functionality
and least privilege.
One applies to objects, one applies to subjects.
So assigning minimal rights and permissions to a subject,
that's gonna be least privilege.
And removing unnecessary services,
protocols, and applications from an object,
that's gonna be our principle of least functionality.
So least functionality,
removing unnecessary services,
protocols, and applications from an object,
survivability, which is a system property.
Least privilege,
which is assigning minimal rights and permissions
to a subject,
and default deny where access is not allowed
unless explicitly specified.
Do you agree? Do you like it?
Let's check it out.
And that is correct.
Awesome. Let's move on.
This is our last question.
"You're meeting with the SecDevOps team
and discussing secure design options.
Now, the goal is to create protection mechanisms
that users routinely apply
and they rarely attempt to circumvent.
Which principle best describes this goal?"
An open design,
separation of duties,
securing the weakest link,
or psychological acceptance?
If you need to put me on pause
while you read through those again.
But our goal is to create protection mechanisms
that users routinely apply, right?
They're cool with it and they rarely attempt, if ever,
hopefully never, attempt to circumvent it.
So what principle are we talking about?
Open design,
separation of duties,
secure the weakest link,
or psychological acceptance?
Well, open design means that the security of the design
shouldn't depend on being hidden, right?
It's open. You can see what it is.
Really, our response is idea of security through obscurity.
Separation of duties, I gave you that example
when we talked about the wire transfer
where user A could create the vendor,
user B could create the payment,
and user C would authorize it.
The idea is that we separate a duty into smaller tasks
and no one person, no one subject
is in complete control
or has complete decision-making powers.
Securing the weakest link,
well, that's just what it sounds like.
I'm going with this one. Psychological acceptance.
It's all about how the user
perceives those protection mechanisms.
We wanna make it easy and comfortable for them,
not inconvenient.
We want them to routinely apply
and we don't want them to say,
"Oh, I'm gonna circumvent that. I'm gonna get around it."
So that would be the principle of psychological acceptance.
Agree? We'll check it out.
And it's correct.
Congratulations. Great job.
I hope you got them all right.
Up next, we're gonna move into Module 3,
which is Security Architecture.
And we're gonna start with Lesson 10
to compare and contrast security implications
of different architecture models.
So I'll see you there.