- Welcome to lesson nine,
explain the purpose of mitigation techniques
used to secure the enterprise.
In this lesson, 9.1,
we're gonna focus in on secure design principles.
Now, the goal of secure design engineering
is to develop trustworthy and survivable systems.
So what do we mean by survivable?
Well, survivable or survivability is a system property
and refers to the system's ability
to prevent, to mitigate and to recover from cyber events.
Now we're gonna be looking
at three sets of secure design principles:
secure design planning principles,
secure design configuration principles,
and secure design relationship principles.
There's a lot here.
So we're starting with secure design planning principles.
There are five principles we're gonna talk about:
threat modeling, keep it simple,
default deny posture, fail-secure, and an open design.
Again, these are planning principles.
So threat modeling says we should use threat modeling
to anticipate threats,
and we're gonna focus on undesirable consequences.
Again, this is in the planning phase.
So what are the threats?
Remember, threat is a potential danger,
and we're gonna focus on those undesirable consequences
so that when we're planning, right,
we can minimize the risk of that threat ever materializing.
The second is, keep it simple.
I love this one.
This is that security mechanisms
should be as simple as possible.
Now, simplicity means that fewer possibilities exist
for error, and the assessment process is much less complex.
Third, we have default deny.
Now, that's the idea that we're gonna base access decisions
on permissions rather than exclusion.
So this means that by default, access is gonna be denied,
and that the protection scheme identifies conditions
under which access is permitted.
So let me give you an example.
A firewall that is configured in default deny posture
would not allow any ingress or egress traffic,
incoming or outgoing traffic,
until we set up rules in our access control list
that said it was allowed.
But a firewall that was set up in the opposite,
which is default allow,
which say all ingress and egress traffic is allowed
until we set up a rule
in our access control list that disallows it.
So what we're saying here is,
we don't wanna use default allow.
We do wanna use default deny.
We also want to use the principle of fail-secure.
The idea of fail-secure
is that in the event of failure, access will be denied.
So going back to our firewall example,
maybe we have to go through our firewall
to get out to the internet.
In fail-secure, if our firewall failed,
we wouldn't have any access to the internet.
Everything would be closed or shut down.
Lastly is open design.
And that's the planning principle
that a security mechanism should not depend
upon the secrecy of the design
or the secrecy of the implementation.
It's really succinctly our argument
against security through obscurity
because ultimately everything is knowable.
Our next set are secure design configuration principles.
Secure the weakest link,
defense-in-depth, least functionality,
appropriate disclosure,
and sanitize data sent to other systems.
So secure the weakest link is saying,
when we're doing our configuration,
identify and strengthen your weak links
until you get to an acceptable level of risk.
Defense-in-depth, we've talked about this one a lot.
This is to utilize multiple layers of diverse controls
including endpoint protection, such as a host firewall.
The idea is multiple layers of diverse controls.
Remember, we'd wanna make sure
that our controls are independent
and that they're not subject to any type of cascade effect.
The principle of least functionality
says that our systems and devices
should be configured to provide only essential capabilities
and specifically prohibit or restrict
the use of any and all unnecessary functions, ports,
protocols, and services.
Appropriate disclosure is that error and system messages
should not include any unnecessary information
that may lead to a compromise of security,
or could be used for reconnaissance purposes.
And we saw that in an earlier lesson
when we looked at the security-in-action case study
that had the Yellow Screen of Death.
And then lastly, sanitize data sent to other systems.
The idea is that we wanna sanitize all data
passed to complex subsystems
such as command shells, relational databases,
and commercial off-the-shelf software known as COTS.
Why do we wanna do that?
Because we don't necessarily trust those other systems.
Our third group is secure design relationship principles.
Our principles are zero trust, trust but verify,
separation of duties, least privilege,
and psychological acceptance.
Now, we talked at length early on about zero trust,
the idea that there's no default trust or privilege,
and that verification in the form
of re-authentication is required
over and over and over again for access.
Trust but verify is that our dependencies
are not going to be trusted
until we prove them trustworthy.
Separation of duties is breaking a task into segments
so that no one subject is in complete control
or has complete decision-making power.
So let me give you an example.
Let's say that your company pays their vendors
with a wire transfer.
Well, we wanna make sure
that we don't have just one person
who could set up a vendor and say,
"Here's how much we're gonna transfer," and then transfer.
So in the separation of duties,
we could have user A
who can log on to the wire transfer program
and the only thing they can do is set up a new vendor.
That's their whole job.
They can't do anything else.
They can set up a new vendor.
User B, when they log in, they can't set up a new vendor.
What they can do is set up a payment for a vendor.
They can't authorize it, they can't set one up.
They can just say,
"Okay, we're gonna pay this vendor $10,000."
User C, when they log in,
the only thing they can do is authorize a payment.
They can't create the payment, they can't create the vendor.
So we had user A doing the vendor,
user B doing the payment,
user C doing the authorization.
So we had a complete separation of duties
so that no one subject was in complete control
or had complete decision-making power.
The principle of least privilege
is that we're going to give a subject or a process
only the rights and permissions
needed to complete their assigned task.
We're not gonna give them any rights
and permissions that aren't necessary.
Why do we wanna do that?
Well, we know that an exploit will execute
in the security context of the locally logged in user.
So we wanna make sure that that security context
is as small and tight as possible.
And lastly is the idea of psychological acceptance
that the human interface that's being designed
should be designed for ease of use, right?
Should be really easy to use.
No question, because we want our users
to routinely and automatically apply
those protection mechanisms correctly.
We don't want them to make errors,
we don't want them to be confused,
and we don't want to get them frustrated
so that they try to circumvent the controls.
So that would be the psychological acceptance.
All right, that my friends
brings us to our three-second challenge.
There was a lot of information here.
I'm gonna give you five questions, three seconds each.
Let's see how you do.
In the event of failure, access is denied.
So what principle is that?
In the event of failure, access is denied.
One, two, three.
That's gonna be fail-secure.
Question two, the opposite of security through obscurity.
The opposite of security through obscurity.
What do you think?
One, two, three.
That's gonna be an open design.
Number three, no inherent privileges.
One, two, three.
That's gonna be zero trust.
Number four, multiple layers of diverse controls.
Ah, everybody's gonna get this one right.
Are you ready?
One, two, three.
That's gonna be defense-in-depth
or layered controls or layered security.
And number five.
So when I just gave you the example for breaking a task
into segments so that no one subject is in complete control.
One, two, three.
And that's gonna be separation of duties.
So let's do a security in action.
Let's apply our knowledge
in terms of psychological acceptability.
The principle of psychological acceptability
recognizes the human element in computer security.
If security-related controls are too complicated,
or cumbersome, or inconvenient,
the user's either gonna ignore them
or they're gonna find a way to work around them.
So you're reviewing a software design
that prompts the users whenever a new patch is available
and gives them the option to install and reboot or ignore.
Hmm. What is your assessment of this approach?
Again, we wanna make sure that whatever we're doing,
our users don't see as being complicated, cumbersome,
or in this case, inconvenient.
Go ahead and put me on pause,
jot down your notes of what your assessment is
of this approach
and then come back and we'll do it together.
Well, here is probably your assessment.
Most likely, the prompt is gonna be ignored, right?
So we're giving them an option,
install and reboot in the middle of their workday,
or ignore it.
So what do you think 99% of the people are gonna do?
They're gonna ignore it, right?
They're gonna say, "Okay, I can do that later.
You gave me the choice to ignore, so I'm gonna ignore it."
Now, a better approach
would be to maybe include a brief description of the patch
and severity level.
So the patch is doing X, Y, Z, and it's critical.
That might prompt the user to take the right action.
We may wanna give the user an option to schedule the update
and the reboot so they don't have to do it right now
'cause you're in the middle of the work.
But do you wanna schedule it
for maybe five o'clock when you're done for the day?
And if it's a critical patch,
maybe we're gonna allow just a very short grace period
and then require installation.
So we're not gonna give them an option.
We might say, "Listen, you have five minutes
to save your work because this patch must be installed.
It is absolutely critical."
But we wanna be sure to be very, very clear about this.
So the goal is that we wanna be partners, right,
with our user community.
We want them to understand what we're doing
and we don't want them to ever feel
like it's burdensome or inconvenient.
And we definitely don't want them circumventing
our controls.
So being able to do this type of assessment
and have this conversation with your user community,
absolutely, you know what it is, it's security in action.
There's your word cloud.
There's a lot there.
We covered a ton, a ton of different principles
and concepts.
These are all really important.
I would expect to see these on your exam.
Well, really, just like everything else
probably in this course, but these are really important.
So make sure you can speak to all of them.
Go back to the lesson if you can't.
And then when you're ready, hop on over to the next lesson.
I'll be waiting for you there.