this is cloud security orienteering uh
thanks everyone for sticking with us i
know we're right towards the tail end of
what's been a really exciting conference
i'm actually going to end up referencing
things from just the last day or two
as we go through these slides i'm ramy
mccarthy i'm a staff security engineer
at cder which is a health tech startup
i'm what i like to call a reformed
security consultant with ncc group
i have a couple certifications in cloud
security and i was a core contributor to
scout suite which is a multi-cloud
auditing tool and released an open
source vulnerable terraform
configuration tool called sad cloud
so
we're going to dive right in here to the
background um
what is orienteering i don't know if
anyone googled it after it was in the
talk title but in the general sense it's
an outdoor sport really where you use a
map and a compass to navigate from point
to point in diverse
and normally unfamiliar terrain um at
speed and so in my background as a
consultant i did a lot of aws security
assessments and a lot of gcp assessments
and azure these were sprawling multi-uh
account environments
um in some cases and in other cases it
was one account or one project or
subscription that had a ton of resources
intermingled and so i well i was being
paid to do a security assessment i
really need to establish this
methodology for orienteering for finding
my bearings and
finding my way from point to point at
speed in an unfamiliar terrain
now
understandably most of you are likely
not security consultants um i am not a
security consultant anymore how is this
relevant to you
well when you start a new job or a new
team as a cloud security engineer this
is going to be exactly the sort of work
you have to do to get your bearings
if you are a consultant or decide to do
some consulting engagements similarly
this will come into play
a merger acquisition is going to be an
opportunity for you to very quickly
understand the current state of an
environment
and then you're going to want to see
your own environment with fresh eyes
hopefully following this there's
something that's applicable even if you
feel you have a fairly good handle on
your
own company or organization or account
before we can talk about security at all
or orienteering we need to look at how
so many environments get into the state
they're in
and really that comes down to cloud
adoption patterns and securosis which is
a really incredible information security
advisory firm has broken out these four
common patterns of cloud adoption and i
recommend their whole blog post it's
really enlightening
but this is a short synthesis here there
are the four patterns developer led data
center transformation snap migration and
native new builds
and there's a pattern a trend you can
see here which is that
in three of the four cases security is
either late or trailing implementation
uh
and that results in higher variable risk
and so really
because of the nature of how the cloud
is adopted in businesses we're
inherently going to have these
heterogeneous risky environments and
that's why it's important to be able to
discover what the risks are and also
know how to prioritize them
appropriately
so you walk into a cloud environment and
unless you're like very very lucky this
is a pretty fair representation of what
it's going to be like
there are a lot of reasons for this
we'll go into but basically the cloud's
a new concept in the grand scheme of
things there are standards and best
practices that are elastic and evolving
uh and security trails behind cloud
adoption and so you end up with these
environments that uh there's a lot wrong
and us as security practitioners we need
to know how to handle that appropriately
so if we're going to talk about the
current state of the environment we're
going to criticize it we need a clear
and well-founded definition of our
target state what does good look like in
these cloud environments
and this can be hard in cloud
architecture for a few reasons uh like
we've said the standards are emergent
there's a high complexity ceiling and
there's a ton of configuration uh and
services you know in aws it's 200 plus
150 of which have security documentation
at all
and this is true across all the cloud
service providers
so quick programming note from here on
out i'm going to use aws for all the
examples we're going to do our best to
talk about principles here not any
specific clouds
defaults for example
and nothing that shouldn't be applicable
to other cloud providers no matter if
you use gcp or azure or even for the
like one person in the audience who has
a workload in oracle
so
what does good look like in aws
what comes to mind when i say aws
architecture security best practices
maybe for some of you it's the aws well
architected framework which has a
distinct security pillar
for others maybe it's the aws security
reference architecture which is this
uh prescriptive guidance they've
released as part of their solution
architecture
um that you know
climbs with cloud formation to set up a
perfect environment for you
for newer folks and newer teams maybe
it's control tower i haven't used it a
lot but it's a prescriptive offering
from aws that will set up
you know as it says on the slide secure
compliant multi-account aws environments
what i'm getting at here is the
complexity of the fact that in the last
10 years
all of the cloud providers have been
rapidly improving and iterating on their
recommendations they've been building
new features new services for security
for governance for compliance for
orchestration
and you're going to see permanent
architectural evidence as you go through
a cloud environment on where an
organization started its cloud security
journey
if you take for example aws
account management aws organizations
which is now a standard recommendation
and expectation for most organizations
weren't even around until 2017 and so
it's super common if you walk into an
organization that's been around any
longer than that and most have
they're going to be accounts that either
had to be shifted into aws organizations
they're going to be orphaned accounts
and it's very common they just predate
this construct
as another example we can break down the
aws security pillar white paper this is
directly inspired by scott piper who
back in 2018 did a diff of the update to
the white paper
and at the time it was super interesting
because aws recommended guard duty for
the first time really comprehensively as
well as shield waff and firewall manager
um
they used to recommend elasticsearch emr
and athena and move to just athena for
searching analyzing logs cloud formation
and therefore infrastructure as a co as
code took a key place
and macy this was at the time that macy
was being criticized for the pricing
model and its utility and was fully
removed from their best practices
i've gone and done the same thing for
2018 to 2020 which is the last year the
white paper was released uh following
that they moved to html documentation
and as you can see a lot changed just in
those couple years um database
organizations as we talked about uh had
really matured in that time federated
identity was now called out as a best
practice aws security hub and config
were a core part of the guidance as well
as movements towards automatic
remediation
scps were coming in as part of aws
organizations and they significantly
expanded instant response guidance
so when we talk about best practices you
have to remember that at the time that
organizations may have configured
workloads in the cloud the best
practices and even available tools may
have looked very different than they do
now
so
what does good look like in aws i said
there's not one answer i said it's been
changing but for this talk for reference
i'm going to be mapping roughly to three
standards when we talk about best
practice security configuration we're
going to be return referring roughly to
aws cis benchmark
for architecture i'm going to generally
be aligning to
uh scott piper's sorry for architecture
well architected framework for cloud
security maturity scott piper's aws
security maturity roadmap which is
phenomenal
so
you have the rough guideline here
let's talk about orienteering right we
have a few standards we can look at for
best practices
uh we understand that cloud adoption is
elastic and that over time these
expectations have changed and this is
why we have these heterogeneous accounts
how do you actually find resources and
know what's going on
first some assumptions this guidance is
going to work assuming you have
cooperative help
uh you need to be partnering with devops
with developers with operations team
sysadmins and leadership to gather
information
i'm assuming companies had good
intentions and are doing
some of the basic things right but that
this is the first concerted effort at
security architecture
i'm not talking about multi-cloud this
is not an indictment there are plenty of
those floating around but you're on your
own if you want to figure this out for
multi-cloud um certainly apply it to
each cloud but then you have to worry
about the matrices
and we're going to assume that you have
access i'm not going to talk about how
to break into an account that you know
exists in your company owns there's a
lot of good blog posts out there that
give you guidelines on how to regain
access to an aws account
and finally it's important to be aware
that when you're doing this sort of
discovery work you often will stumble
upon some really scary things and it can
turn into instant response um we're not
going to cover that situation here
there's no expectation of active or
historic compromise and cloud instant
responses it's whole genre
so
principles of orienteering
breadth and depth um this is actually
something i see junior analysts and
security practitioners falling into
really commonly is that they'll see
something interesting and
part of the curiosity and discovery of
security is folks who really know how to
dig in and that'll get you in trouble
when your goal here is to
orient yourself before you can dig in
anywhere you have to figure out where
the most important places to do that and
therefore you need to strive for breath
which means avoiding rabbit holes
take a note come back to it but when you
start you're always going to want to
have a good idea of the overarching
situation
anomaly detection is the name of the
game here uh and i just mean pattern
recognition this isn't ml this isn't
automated some of this is gut and
experience some of this is get used to
the norms of a specific environment
make sure you look at every region every
project every account and you should
start to get a feel for what is uh maybe
further drifted from the norms of even
that environment for example if they
have everything running in usc 1 and you
see a resource running off in bahrain
take a note follow up on it
also
another gap i see is take advantage of
your inside out access meaning leverage
the access you have to query and
enumerate efficiently don't try and
emulate an adversary if you have
authenticated access to apis whether you
have security audit or read-only access
use that
but also remember to go outside in
this is the only way to catch these
unknown unknowns in this quadrant uh
credentialed access only works for
things that you know about outside in
and there are a lot of talks for example
felipe and kavisha's talks earlier in
this conference about how to find
unknown resources this is going to look
like dns brute forcing or
certificate transparency logs using
tools like census and showdown
but take advantage of both
get easy coverage of the things that you
already have access to but don't forget
to look for things that aren't
documented or known
[Music]
and then i like to call what we're going
to do corporate archaeology
really what you're doing is you're
digging into the history and artifacts
and organization itself
builds and creates in the process of
deploying these environments and using
that to understand where risk may lie
so corporate archaeology there are a lot
of data sources if you're really lucky
there's a detailed asset inventory
although often it's incomplete or
doesn't exist
if you're a little lucky
they've adopted infrastructure
configuration as code with tools like
terraform or chef ansible puppet
and this gives a definitive source for
cloud configuration
most organizations especially those of
the mature compliance or governance
function should have data classification
and designation of scope
for example even if they don't have a
good handle on their whole estate they
should know really well where their pci
environment is
and then all organizations should have
subject matter experts available as we
talked about earlier hoping for
cooperation here who can pass tribal
knowledge and much of the knowledge in
organizations i've audited is tribal
if you're lucky there's standardized
tagging if you haven't rolled out
tagging in your environment check out
your which automates it um but tagging
can let you do things like query for all
the resources with a certain data
classification level or group resources
by workload or find business owners and
that's really valuable data to use as we
go through this process
and finally i'm going to return to this
idea of cloud security tools but just
remember when you're orienting yourself
in a new environment take advantage of
what they already have if they're
already paying for vendor tools a cspm
maybe
a cloud security posture management tool
use that don't ignore it
and we'll talk about how later
eventually you're going to need to find
develop or have someone build for you
architecture diagrams and documentations
of workloads there's only so much
reverse engineering you can do in this
process
and so start the ask early you know flag
that down the line you're gonna have
detailed questions and they should
figure out what their priorities are
there
you're also going to need no crown
jewels and this is very organizationally
dependent and people overlook this but
in organizations like mine where we're
very regulated and compliant we know
what our major risks are and those are
around protected health information phi
because we're a health uh tech startup
um pci data card holder data in
organizations that maybe aren't
regulated or don't have those compliance
requirements this can be a lot fuzzier
and go and ask ask the business what is
the
riskiest data what would be worst if it
were compromise if it's a ad tech
startup advertising technology is it
their ml models is it the user data
is it their um you know data they've
bought from vendors where there are
strong contractual requirements you
can't know and so you have to ask and
discover that and use that to guide your
prioritization later
also
you need to find what the intended
authentication and identity approach is
there may not be a standard one but
knowing if
uh it's normal for folks to have their
own im users in each account
whether they are using roles and cross
account assumption with an identity
account etc is going to be really
important down the line as we start to
draw everything together
and there's this hierarchy in cloud
environments and you should use it to
your benefit in discovery
we start at the bottom level with the
broadest selection which is collections
of accounts or environments
in aws this would be aws organizations
then at the environment level you have
the point at which there's a default
enforced boundary based on the cloud
service provider so this would be an aws
account which by default is completely
encapsulated
next up you have workloads and then
regions so workloads can span multiple
regions these can actually be flipped
though of course because you can have
multiple workloads in a region
services and then resources used to
implement those
services and this is not ordered it's
hierarchical but it's not a guideline
right we're not going to start with
collections of environments and then
work our way up
instead once you find for example a
workload you're going to want traced in
both directions you're going to want to
find out what the environment it lives
in is
and maybe is that affiliated with an aws
organization or a gcp account and which
and you're also going to want to trace
it down to the individual resources so
this model is important to think about
just in terms of traversing it and
building up a knowledge base
but not necessarily directly followed
for orienteering
so getting into some of the you know
maybe more technical details here how do
we actually do this right
discovering your environments
discovering your accounts is generally
the first step as their
um
the largest unit you can easily discover
finding aws organizations is not
necessarily trivial um finding aws
accounts there are a lot of ways to do
it scott piper over at summit route has
written a whole blog post
uh that i'm just going to reference
directly you know you can work with your
technical account manager your finance
team
search company emails dns logs network
logs
and also put out a request to public
employees and i actually want to dig in
more to this last note here
so
when we're talking about security and
cloud security there's a technical
aspect but there's also a human aspect
and security is all about evangelism to
your organization so how do you reach
out to employees right find them where
they are if your company uses slack just
put out a message and say can everyone
please let me know what cloud accounts
they're using
but you also have to incentivize things
um there are a lot of ways you can
incentivize people to bring accounts
that are shadow i.t under centralized
management
that can be
opening up a new policy where you allow
folks to expense development
environments which will come with some
cost but then guarantees or almost
guarantees folks will bother telling you
once they set one up
you can also offer default profiles for
these accounts offered to stand them up
and manage them offer to be responsible
for maintenance and stability and i say
you offer and i mean as a security team
or as a security team partnering with an
it org
or devops org
and so once you go through that process
and have a starter set of accounts
you're going to want to take a pass at
discovering workloads
and
you can do this from a technical
perspective but i find that the best
place to start is actually documentation
work backwards find where the company
likes to keep records is it github or
git lab is there a confluence or wiki
you can look at and start reading about
what their products are what their
services are what tools they use and how
they're designed and where they live
you can also inside the accounts look at
the monthly billing report any spikes
are important to dig into but also the
monthly billing report in a cloud
account
can be reverse engineered to say a lot
about the architecture
for example lift and shift migration
models
generally result in a huge usage of ec2
instances to replicate on-prem servers
and so that's a really valuable piece of
data on how the company works and has
designed things
that you can learn just from looking at
billing similarly you know how much
adoption there is of various managed
services like container services
and corey quinn who has a uh you know a
well-known startup doing cloud billing
optimization has a whole blog post
discussing how you can tie bills to
architecture that
goes into this in much more depth
and then also infrastructure as code is
specifically useful for workloads
because often
best practices for writing
terraform or similar infrastructure as
code has you group the actual code
in a workload
so that can be mapped you know how
if you look at a cloud account and you
have an ec2 instance and an rds a
database backing it um you know and
maybe a firewall uh maybe a cbn those
resources have to be traced whereas in
infrastructures code they'd probably all
be sat alongside each other
and
i want to flag here besides looking at
discovered accounts here when you're
looking at the documentation you get a
second chance to find accounts based on
novel workloads so
there may be somewhere deep in the
documentation from 2017 where someone
says you know
oh we stood up this service for a single
client or we have a beta running and you
don't recognize the cloud id and that
gives you another chance to find these
things
and then so you have an idea of accounts
you can work backwards to organizations
you have an idea of workloads roughly
what are the sort of things we're using
the cloud for
you should discover resources and i
can't overemphasize you cannot manually
discover all the resources in an
organization's cloud estate of any
reasonable size i've done it i've
literally gone through zoom calls over
the shoulder with clients trying to
navigate their
aws console to find resources and do a
security audit
it's slow it's painful and you will miss
things it doesn't scale it scales
linearly
automation is key there are two paths
for automation like i said earlier we'll
talk about vendors here's where we do it
the company may already have a cloud
security vendor or two in place
cloud security posture management is
gaining wide adoption there are a lot of
really cool tools in this space
maybe also they've just adopted native
cloud security cloud service provider
services like aws security hub and aws
config
you can use these tools if you're
orienting yourself there is no reason
you shouldn't look at this existing data
but there are a few caveats
watch out for exceptions and actually
dig in why are certain things excluded
from scans
uh oftentimes that's because they were
firing too many alerts which can be
false negatives or sorry can be false
positives
but also now you could have false
negatives
also check the configuration if you've
gone through the process to this point
you've probably found some accounts that
the organization didn't know about some
unknown unknowns and it's unlikely those
are onboarded to their uh tooling
so
your other option here is to run a tool
yourself and it's almost always going to
be open source uh if the
company doesn't already have something
that they're paying for
um
so
why is this well procurement is hard
anyone who's worked in a big company
knows it can take months to get sign off
to put in a new tool
and when you're trying to orient
yourself you don't want to wait for
those maturity processes to roll through
so
we turn to open source and there's so
many people writing so many great open
source tools this is just a subset my
former employer ncc group disclosure has
a tool called aws inventory that tries
to identify every resource in a specific
account i also personally really like to
use the auditing tools just for resource
discovery because
as a predicate to actually running
configuration checks they have to
discover the resources and often will
have good reporting on vulnerabilities
and workloads and how services
communicate
steam pipe prowler scout suite are all
targeted at misconfigurations but are
really strong examples of tools you can
use
and native services are really good i
want to specifically um call out gcp has
some great asset inventory tools that
work out of the box that you should
leverage
and for the most part uh asset inventory
tools are
relatively inexpensive but check before
you turn them on so you don't get fired
so
that's the really quick way we walk
through and find resources services
workloads right
but then we have to actually dig in and
talk about prioritization
so
you have more data than you know to do
with you have a decent mental model of
the organization's cloud estate the real
thrust here is how do we go from that to
actual guidance how do we decide what's
important if you try and fix everything
you're not going to get anything done
and you're not prioritizing your time
appropriately
someone in engineering leadership once
described this to me as you know in most
companies everything's on fire all the
time
and the important thing is figuring out
what can be let burn
if you're not carrying any risk your
company's probably being too
conservative and that can impede a speed
of growth
so what's important in the cloud we need
to know it's important to prioritize
identity is the new perimeter but the
network perimeter actually hasn't gone
away in many cases especially in these
uh lift and shift adoption patterns or
other non-native patterns
so we need to look at the realistic
threats here
i like the
uh disrupt ops breakdown of cloud kill
chains
and i'm just going to speed through this
part but we can look
at these threats based on three features
whether they're actually the root of
initial access
whether they're cloud specific and what
the impact is and we're going to
immediately drop anything that's not
high impact
anything that's not cloud specific
probably isn't
solely your job to cover as part of this
process
and if it's not the source of initial
access if it requires another
vulnerability exploit or compromise
it's just not a day one priority
and here's the second set here network
attacks novel cloud day exposure and
exfiltration if we flip back we'll see
almost all of these are either resource
exposure or the account perimeter
um
you know network perimeter or resource
exposure which is an identity thing in
the cloud like s3 buckets allowing any
identity to read
them we can also look at this based on
publicly disposed breaches and i did a
whole talk on this so i'm self-citing
here um but you can see that these risks
align to the kill chains we flagged and
aligned to this idea of identity and
network perimeter credential abuse
exposed resources and application
vulnerabilities all show up here as well
which gives us an indication we're on
the right path
so
environments and collection of
environments
you need to figure out where your target
state's going to be on that front as you
go through this process so you can make
fixes that support a target state are
there accounts that you shouldn't be
digging into fixing because they're not
used and can be deprecated
who is the business owner that you need
to talk to before making potentially
breaking changes
and uh is there even a need for multiple
organizations are you gonna start
onboarding things
look at your workloads check the oldest
ones first they're the most likely to
have problems because no one's touched
them in a while
often they predate certain controls and
configurations and most cloud service
providers don't apply those backwards by
default
and then we get to the identity
perimeter and a lot of people have
talked about kind of i am hardening so i
don't want to spend too much time on it
we're going to restate a lot of these
things though specifically what's
interesting for orienteering is the
management plain access model how are
users getting access to roles in this
cloud is it sso are they using im users
um is it tied to
directory users are they federated is
there an identity account in cross
account roles are they uh accessing each
account directly do they have access to
all roles with the same permissions you
need to start understanding this because
that will give you a good idea of what's
deviant and also the level of maturity
if they're using raw i am users at this
point
you can suspect that there may be a need
for a maturity push on the identity
front
and similarly ssh and server access
model uh ideally there will be one
standard here but often there are a few
are they used in bastion hosts are they
directly sshing into cloud servers which
means they have to be internet exposed
what sort of credentials are they using
are they doing ssm or cloud native
services to access these
uh are they buying some sort of zero
trust cloud native tooling
this will tell you what is a
misconfiguration and what is an
architectural decision so if they
actually if an organization says we
directly ssh into servers
they therefore need to expose those
servers maybe there's a vpn maybe
there's a bastion host but then you know
that maybe those port 22 open to the
world
isn't quite as concerning as it would be
otherwise still something to mature but
not something that's necessarily a major
exposure out of the gate
and we get to i am
there are a few things that are actually
urgent
um
cleaning up the root user is essential
understanding cross count trusts with a
tool like cloud mapper will let you know
if there's anything potentially
nefarious or presenting a lot of risk
with what sort of vendors or partners
have access to your account
and the im credential report is a great
use of a great tool to find unused users
or to find unused roles
and then we talk about the identity
perimeter
and how we actually find this stuff so
like i said the credential report is
great trusted advisor security hub or
aws config all have im findings trusted
advisor there are some included in kind
of the free tier
and then open source tools a couple i
want to call out that will uh help you
prioritize by flagging the highest risks
cloudsplaining from salesforce is really
wonderful because it'll give you a good
idea of the general hygiene with the
number of findings
but specifically it calls out privilege
escalation and it calls out what users
and roles have the ability to expose
data leak data modify infrastructure
eric's actually speaking at
blackhat or defcon about pmapper he just
released a new version it's awesome it
will do transitive access and talk about
highly privileged users so no longer
it's just look at who has admin it's
look at what possible roles can be
assumed for someone to get from their
default permission set to admin as well
as privilege escalation vectors and so
look at these tools but you're not going
to fix the universe of im permissions
nor should you well you're just finding
your way and killing the most important
things instead
you should focus on
high risk that are immediately
exploitable so
too many admins is a bad problem if you
can kill a few of them great privilege
escalation vectors on a standard
employee role are worth finishing
immediately
over privileging of your existing admin
users is probably not a day one job
those are already trusted users and
there are more important things to fix
so
that's the speed round of the identity
parameter then you go into the network
perimeter you need to find public
resources uh github has a collection aws
exposable resources i didn't link to
here
but that is an excellent
way for you to
um tell what the like 42 possible
resources that can be exposed
here's where you dig into your audit
findings right we talked about using
audit reports to find resources
there are a few key findings to look out
for um
anything that's open to the universe is
worth a second glance to make sure it's
intentional
anything that is
yeah publicly exposed
um you need to make sure the workload is
intended to be publicly exposed scan
findings will tell you trust advisor
would tell you this can look like wild
card security groups
um also check all the launch wizard
security groups because those generally
indicate something was made through the
aws console
which is
a sign that things may not be quite as
governed or managed
i said you want to dig into the exposed
resources
um
and this includes hosted applications
and services
uh so
this is somewhere you can really easily
rabbit hole and i want to be clear this
is no deeper than a vulnerability scan
but can't be neglected
find all the exposed ports all the
exposed services and do a quick check
for out-of-date services known
vulnerabilities that might be
exploitable
as we saw application vulnerabilities
are a source of compromise
look at any unauthenticated service and
make sure it's intended to be public and
unauthenticated
and check to make sure you're not
putting things like configuration
management or jenkins out on the
internet these are the ways the
companies get hacked in the real world
and that's why you need to prioritize
fixing them
there are other concerns less actionable
or less impactful but
i want to be clear they're considered
but put aside
exposed secrets there are a million ways
to expose secrets but if you look at
this list
almost all of them are either exposed
outside the cloud environment where you
probably don't have visibility
or they require someone to already have
authenticated access to exploit and
privilege escalation
from authenticated access is an
important day three responsibility but
not day one
find the secrets management pattern and
look at the supply chain um
but fixing vendor relationships isn't
something you can do as part of your
getting your feet wet
and so just make a note and put it aside
and this is my moment for a very short
compliance interlude um
i'm not talking about compliance here
there are compliance professionals i
just want to say if you're working in
regulated industry i'm very sorry you're
not going to be able to follow a lot of
this prioritization because you're going
to have to focus on compliance impacting
controls documented exceptions for drift
compensating controls where you can't
get things enabled
and you're not going to be able to avoid
fiddling with encryption
and a lot of what we're talking about
here is misconfiguration
um this uh
is a gartner report that says
misconfiguration is the root of all evil
um
when you're orienting yourself a new
environment how do you know what's a
misconfiguration
how are you supposed to know the
difference between an s3 bucket called
application files and an s3 bucket
called project meteor right and so this
is where it becomes really difficult to
dig through the data and you should look
at documentation
there's a common
flag when you're looking at securing aws
environments that says s3 buckets being
public is the root of a lot of
compromise and that's not false
but in most environments they're going
to be intentionally public s3 buckets
for static assets and you need to be
really thoughtful about efficiently
figuring out which are intended to be
public and which are risky so that's
where you look at tags that's where you
look at documentation that's where you
look at the classes of data and need to
know what the crown jewels are
um so
miss configurations
hey
hello a few minutes left
awesome perfect i think we're right on
time misconfigurations are really an
argument about defense in depth and i am
by no means against it defense in depth
is a core security principle that you
should be applying to your environment
however in the short term
a fixation on defense in depth is
leaving gaps in your controls it's
better to have your first line of
defense configured before you invest in
defense in depth
and encryption is the canonical example
here i'm by no means recommending that
encryption is useless entirely or that
you shouldn't leverage encryptions
available
but i am saying that if you can avoid
encryption if you're not regulated it's
probably not your top priority to fight
getting old resources onto
ebs encryption for example uh it's still
useful and you definitely should turn on
the default encryption going forward but
it's probably not your top priority
how do you prioritize misconfigurations
there are a lot
of controls and a lot of
misconfigurations aws foundational
security best practices has grown in
size from 31 to 141
the ones that matter we go back to our
identity and network perimeter exposed
management ports exposed resources
lack of authentication are the things
that'll bite you immediately
and i'm going to use my last couple
minutes to talk about where you go from
here
blanket aws hardening always turn on
guard duty always turn on cloudtrail
backup and centralize cloudtrail im
access analyzer security visibility to
all accounts s3 block public access
other people have mentioned these and
it's because they're a really good idea
and there are very few environments
where they're not applicable
what does fixing things look like it's
an exercise in relationships this is a
really kind of canonical book on how you
build a security program
it says seven steps and this is true
when you're orienteering once you have
all this data and you know it needs to
be fixed and maybe where the
architecture needs to go
cultivate relationships get alignment
focus on key security domains get buy-in
from other teams through evangelism and
invest in convincing and working with
other teams
make business owners own security in
their areas
build out a team and measure what
matters
as you can see this is a whole book but
i want to say that you're not going to
fix all these things alone so you need
to figure out what your priorities are
and how you're going to convince folks
to buy in on those fixes
fixing things otherwise is just going to
look like whack-a-mole um it's a
marathon it's not a sprint you're not
going to get everything up to code
immediately or in the near future
i recommend approach of governance with
exceptions in the long term so set a
best practice standard and just track
drift against it and report on it
measure what matters and slowly buy down
that security debt
make sure you're explicitly tracking
these legacy resources and drifts
there are a lot of maturity models cloud
security maturity model is one option
marco lancini has the road map at cloud
sec docks that i recommend look at these
pick the one that fits your environment
if you want to learn more
the slides will be up after this talk
and you can dig in here cloud security
roadmap is great matt fuller's so you
inherit an aws count is a different take
on a lot of the same content
and other resources are here as well
so i don't think we actually have time
for questions necessarily but thank you
thanks the organizers slides will be up
at that link come work with me