Security by Design: Ten Principles
Key Points
- Embedding security from the outset (“shift‑left”) dramatically reduces vulnerability remediation costs compared with retrofitting security late in the development lifecycle.
- The Principle of Least Privilege mandates granting individuals only the minimum access required for their role, with temporary permissions revoked when no longer needed, thereby shrinking the attack surface.
- Defense in Depth requires layering multiple, interdependent security controls across all system tiers—endpoint, network, application, and data—so that an attacker must defeat every layer to succeed.
- Focusing on the design phase allows teams to integrate these principles early, creating more elegant, cost‑effective, and resilient systems than costly after‑the‑fact fixes.
Full Transcript
# Security by Design: Ten Principles **Source:** [https://www.youtube.com/watch?v=3l8GwLv2f3E](https://www.youtube.com/watch?v=3l8GwLv2f3E) **Duration:** 00:17:18 ## Summary - Embedding security from the outset (“shift‑left”) dramatically reduces vulnerability remediation costs compared with retrofitting security late in the development lifecycle. - The Principle of Least Privilege mandates granting individuals only the minimum access required for their role, with temporary permissions revoked when no longer needed, thereby shrinking the attack surface. - Defense in Depth requires layering multiple, interdependent security controls across all system tiers—endpoint, network, application, and data—so that an attacker must defeat every layer to succeed. - Focusing on the design phase allows teams to integrate these principles early, creating more elegant, cost‑effective, and resilient systems than costly after‑the‑fact fixes. ## Sections - [00:00:00](https://www.youtube.com/watch?v=3l8GwLv2f3E&t=0s) **Design‑Phase Security: Shift‑Left Principles** - The speaker explains why security must be baked into software early—especially during design—by illustrating cost impacts of late fixes and introducing the principle of least privilege as the first of ten secure‑by‑design guidelines. ## Full Transcript
the best security is the kind that's
baked in not bolted on after the fact a
retrofit is always going to be more
expensive and probably not as elegant
let's take a look at the development
process if I start looking at
requirements design Code test deployment
and then map out the cost of a security
vulnerability in terms of which phase
it's found it turns out it looks about
like this so it is way more expensive if
you find something in deployment than if
you find it earlier in the process so
the big desire here in this case is to
try to shift left in this process in
other words bake the security in build
it in from the start in this video we're
going to focus specifically on the
design phase and I'm going to give you
10 principles for security by
Design okay let's take a look at the
first secure by Design principle it's
what we refer to as the principle of
least privilege it means don't give any
more access than is abs absolutely
necessary for any person to do their job
function so let's take a look at this
imagine a company has different
classifications of the information they
have of the data that they have so let's
say they have internal use only this is
something we don't really want the whole
world to see but if they did it's not
the end of the world then we have
confidential stuff that really would be
very sensitive stuff and then we have
the keys to the kingdom now here is a
general user and we may give them just
access to the internal use only and
maybe some very specific cases of
confidential information where we
segment that off this guy over here
though he's the administrator he's got
access to the keys to the kingdom which
then in fact allow him to get to any of
these other kinds of things as well so
obviously we need to have that very
locked down we don't want to give
everyone access to everything and maybe
in some cases we give this person
temporary access to something else that
falls into this realm but then we remove
it as soon as they don't need it anymore
that's the principle of lease privilege
each one of them has only what they need
in order to do their job and only for as
long as they need it and not any longer
than that that reduces the attack
surface the next principle we'll take a
look at is defense in depth defense in
depth says I never want to rely on any
single security mechanism to secure the
entire system I want to have a system of
interrelated uh defenses and make sure
that they all would have to fail in
order for someone to actually get into
the system so let's take an example here
here's an end user and they're going to
use some endpoint device a laptop in
this case could be a mobile device uh
coming across a network to hit an
application which pulls data from a
database so that's a typical use case a
typical architecture that we might see
here so I'm going to look at each one of
these layers and try to secure each one
of them for instance here I need some
ability to do identity and access
management I might need need things like
multiactor authentication and other
things like that to ensure that the user
is who they claim to be we would also in
the identity governance part of this
make sure that we've adhered to the
principle of lease privilege and only
given them what they need in terms of
access rights and then here we're making
sure that it's really them so we design
these things into the system in order to
be the first layer of Defense the next
layer of Defense then is on the device
itself and we do things like unified
endpoint management to make sure that
the device is configured as it should be
it doesn't have viruses or malware or
anything like that uh it's got a strong
password if that's the way we've done it
it the information's been encrypted on
it a lot of things like that so uh that
has to also be secure the network also
needs to be secure we're going to use
things like firewalls Network intrusion
prevention systems and other things like
that that there's in fact a lot of
different technologies that go into this
space but the idea is I'm not relying on
just any one of those things there are
multiples and they're all looking over
each other and verifying the application
well what are the things we might do
there well I'm going to put in access
controls so I want to make sure that the
application only allows certain levels
of access again implementing principle
of lease privilege I'm going to scan the
application for vulnerabilities I'm
going to scan the source code I'm going
to scan the operational system in both
cases uh a lot of other things that we
can do in that space and then finally
the data itself we're going to encrypt
it so we're we're going to use
cryptography in order to make sure that
the data if it does leak isn't easily
seen by others and we're going to do
things like backup and Recovery
capabilities so that if for instance a
malware comes along and blows this thing
away ransomware case I can recover
quickly so you can see the point here
there's no single mechanism that is
providing security it's a whole system
of interrelated defenses that work
together in order to make the system
secure our next secure by Design
principle is the principle of fail safe
fail
safe assumes that any system will
eventually fail because Murphy's Law
right anything that can go wrong will go
wrong and it will especially in these
cases so let's take a look at what a
system should do with if in fact it does
do one of those failures so let's take a
look at a firewall let's say we allow
this traffic to go through but this
traffic we block so those are examples
of the firewall operating the way we
expect a firewall to operate now let's
take a look at another example where the
firewall has in fact failed something
has gone wrong with it now what
condition is it going to be when it
fails does it become a permanent block
until we fix it or does it become an
open switch so what we don't want is for
anything to get through that means even
the good stuff we certainly want to
block the bad stuff but for sure block
even the good that's what's called fail
safe the condition is it fails but it
fails in a secure position that's what
we want now the next one that we're
going to take a look at is kiss
principle this is keep it simple stupid
now a longer version of this is economy
of mechanism which even in and of itself
is too long so let's get rid of that
name and let's go with kiss keep it
simple stupid if I'm trying to get from
here to here what I don't want to do is
tons of twists and turns because each
one of these twists and turns introduces
more complexity and complexity is the
enemy of security the more complex a
system is the harder it is to ensure
that it's going to do in fact what we
want it to do so what I want to do is I
want to make the system as simple as it
possibly can be and in making it simple
I reduce additional vulner abilities our
next secure by Design principle is the
principle of separation of Duties
sometimes called segregation of Duties
but it's the same idea so with
separation of duties I'll give you an
illustration of this imagine a door with
two deadbolt locks each with a different
key and I'm going to give one user one
of these keys and the other user the
other key now if I lock both of those
locks nobody is opening this door unless
both keys have been used to unlock it so
in other words I've spread the ability
to open the door across two people why
would I do that because now it makes it
harder for one single bad actor to do
something bad to the system it requires
collusion in order to break into this
system so separation of Duties is a good
principle to keep up another one is
about open design I want the system to
be clear and open it's the opposite of
security by obscurity which is something
that no one really tries to design into
a system but a lot of people feel secure
if they think no one knows how their
thing works so to give you an example to
borrow from cryptography there's this
thing called cryp uh Kirk off's
principle and kirkoff came up with the
idea that says if I have a crypto system
so that means I'm going to take plain
text that anybody can read I feed that
into my encryption system and I'm going
to get out a bunch of gibberish
something that's an encrypted message
that means that uh the only thing that
someone should should really keep as a
secret would be the key the key that's
used to encrypt that data so this person
trying to observe the system if they
can't see into it they really don't know
if this algorithm is good or not it
could have all sorts of vulnerabilities
that are hidden that no one has been
able to see because the inner workings
of the system have been kept secret a
better idea is following Kirk off's
principle where we actually take the
plain text we feed it into the system we
see how it works and we see how it
creates the cipher text the encrypted
version of all of that so the only
secret in the system is in fact the key
the way the system works is visible by
anyone and that's how the best crypto
systems in the world work it's not
security by obscurity it's security
through openness our next secure by
Design principle is is that of
segmentation that is there are going to
be times when we specifically want to
break the system up into pieces and that
those pieces create a certain amount of
isolation that give us additional
security take for instance here's a
townhouse and let's say these folks here
have a fire and that fire is affecting
their unit what we don't want to have
happen is for that fire to spread so we
put literally in construction between
these units something we call a firewall
that's where we get the term firewall
from by the way on the network side but
this is in physical architecture this
firewall is designed to the and
slow down the spread of fire from one
unit to the next so that way the fire
department can get there put the fire
out before it burns down the whole
building that kind of segmentation is
also what we do with our networks and
what we do with our security we take
components that are of one level of
security and put them in one area
isolated from other areas that may have
different levels of sensitivity so this
idea of segmentation can be designed
into a system to make it more secure how
about another factor that often gets
overlooked and that is we forget that at
the end of all of this security chain is
a human and the humans are often the
weakest link in that chain so we should
really be looking at
usability human factors if we make a
system too hard to use well then people
will find ways to get around the
security because not because they're
evil just because they need to get their
jobs done and they don't understand the
reason for all that complexity here's a
good example of how the security
department has made things difficult and
made things as a result less secure in
the way that they designed the system so
we put the requirements for instance
with passwords we say your password has
to be um let's say uppercase characters
it has to also include some lowercase
characters uh it has to include some
numerics some numbers along the way it
needs uh some special
characters um it needs to be of a
certain length let's say it's got to be
32 characters long or or longer
something like that um let's say we're
also going to add in that it has to be
unique um and it needs to be unique
across each system so it's not the same
password on multiple systems we're going
to make sure that that this is not uh
going to be replicated and it needs to
be fresh so we're going to make you
change it frequently all of these things
go into what would theoretically be a
very strong secure password but what do
end users do when they look at all of
this they say well I can't remember that
if I had multiple passwords that were
that level of complexity I can't
remember it so what am I going to do
well it turns out there's a solution
that the end users came up with for this
and it's this this is the first p
password storage device that users turn
to and they put all of these things up
on their monitor somewhere no one will
ever suspect to look right and it won't
matter how strong the password rules are
if people end up doing this you've
created an insecure system so make sure
when you design a system you design it
to be usable as well as
secure if you were aiming at a Target
which ones of these Bull's eyes would
you prefer the big one or the little one
if you're trying to hit the target
probably like this one but if you're
trying to secure an infrastructure you
want to present this to the outside
world you want to in fact minimize the
attack surface you want to make it so
that it's really hard for somebody to
thread the needle and get right to where
your sensitive stuff is so I want to do
that by limiting certain things so for
instance I'm going to limit maybe
external interfaces that I have is there
really a need for that thing to be
connected to a lot of other systems
along those same lines I may want to
limit remote access is there really a
need for people to connect into this
system from outside or would all the
access be from a certain place or there
are only certain IP addresses certain
ranges or areas of the world where we
know legitimate users would be so I
could do some sort of limitation there
and again reduce the attack surface how
about limit the number of components
that are in the system
again this kind of goes back to the keep
it simple fewer number of components
also minimizes the attack surface and
there's a lot of other things that we
can do in this space but you get the
general idea I want to make this into
that so it's really hard for the bad guy
and then our 10th principle of secure
design is in fact
secure by
default so this now deals with the way
the system operates in its default
configuration when it just comes out of
the box what is it going to look like so
take a look at two houses here's a house
that is insecure by default the front
door is wide open the windows are open
those are all attack surfaces and the
way it's set up right now it is insecure
we look at this house in this case the
door is in fact closed we'll say it's
locked the windows are down so secure by
default so what are some of the
principles then that we would look at in
some of these cases so it would be
things like a secure insecure by default
would be by default everything is turned
on all the features of the system are
turned on versus secure by default would
say only the required uh capabilities
are turned on so I'm going to make it so
that I've limited again attack surface
I've limited the possibilities of a bad
guy to exploit because only the things
that are necessary you'll see that a lot
of these principles relate to each other
that's again very similar to principle
of lease privilege then defaults also
very important since we're talking about
that is the default password configured
and if it is well then that means it's
going to be be the default on all of the
systems all the instances of that system
so if it's a consumer product everyone
that buys that then they're going to all
have the same password unless it gets
changed it's much better if you make
people Supply a password something
that's determined during the
configuration and set up the system that
way you end up with uniqueness otherwise
someone can just go out and figure out
what's the default password for this
particular device and assume that people
have not changed that password and then
they'll be able to get into all of those
so we're going to make it a must Supply
how about default IDs especially if
those IDs are the administrator ID the
super sensitive stuff if it's an admin
ID maybe I want to make it so that when
you uh actually configure and install
the system you have to pick a different
name for that you have to pick something
that's going to be unique so you've made
it harder for the bad guy because now he
has to guess what is the admin account
what is the admin password and then all
of the capabilities that they might
normally use to break in through those
have been turned off so these are the
kinds of things that we're looking for
secure by
default getting security right isn't
easy but now I've given you 10
principles for secure by design that way
you can make sure that security is baked
in from the start and not a bolt on at
the end that way you save money and make
your system more secure at the same time