[music playing] Good morning everyone and welcome
to the Leadership Session For the Security, Identity,
and Compliance Track. My name is Steve Schmidt
and I’m very pleased you could join us
this morning for a topic which I hope is as near and dear
to you as it is to me. That’s AWS security,
identity, and compliance. We’ve got an awful lot
to cover in the next hour, so let’s jump right in. The first thing I want
to get into today, with you virtual folks, is those highlights and
announcements you may have missed. The AWS pace of innovation
is really something to behold. Just in security I think
we’ve averaging nearly a new feature or service update every day,
not to mention all the other services you interact with
on a day to day basis. But all that augmentation
and improvement might mean you might miss something that is going to help you
secure your environment. So, we went out
to our security experts and asked them
for the new features they found to be most impactful
to their work. We’ve rounded all of those up and put them together
in a title list for you today. The second item, we’ll get into
the space I know lots of people will tune in
to reinvent for overall. What are the net new things
I can do in the cloud today, the new announcements,
the fun products and features? What are the new bells
and whistles I can try out and experiment a little
if I haven’t seen them before? So, I’ll be breaking
those down for you. Next up, I want to get into
Zero Trust, that’s a place we’re seeing
a lot of focus and questions from customers right now,
so I thought it might be helpful to discuss how AWS thinks
about the main themes of Zero Trust as well as how AWS
can help you apply those concepts. Finally, I’ll leave you
with a real life mix of tactical things
that you can do today and a few strategic places that
I think may be worthy of your time. This ten places to focus
today section, drove significant
positive behavior last year, so we wanted to bring it back and also update it
with some new advice as well, so here we go.
The 2020 security highlights, we’ve got a bunch of these
to get through, so this will need
to be a speedy update. Most of these should have
some relevance to the security work you’re handling out there. Before we start this section now,
a quote to set expectation, I would say Mario Andretti
had the right idea about speed here. And AWS innovates at a pace
that can feel at times as if you’re accelerating
into a turn. But what’s the alternative? If our philosophical choice
is between innovating for customers and not innovating, I think you can guess what
the decision’s going to have to be. After all, there is reason Jeff Bezos
wanted to name Amazon, Relentless, back when he was starting out. Which brings us to, Amazon GuardDuty. We announced a new capability
this summer for GuardDuty. We now have S3 data events
as a new log and event source that GuardDuty
will continuously monitor. This gets you
extremely helpful insights on data access behavior
and threat intelligence. Specific things such as unusual
geolocation activity, API calls from a known
malicious IP address. Or API calls consistent
with data discovery attempts. Basically you can now have
GuardDuty monitoring both data access events
and S3 configurations. You might know those
as control plane APIs. GuardDuty is a security service
I love. It’s using anomaly detection
and machine learning and continuously updates
its threat intelligence both that we get
from the outside and that we develop ourselves,
to accomplish all of this. To get started, if you have
GuardDuty enabled in a region, you go to the GuardDuty console, select S3 protection
and then click ‘enable’, that’s it. That’s the complete list
of things you have to do. You repeat the same process
for the other regions you’ve got your account,
but it’s that simple. You’ll start seeing new findings
within a few minutes. Please consider doing this, folks, you might be surprised
with what you find. Now, while we’re on GuardDuty, let’s throw AWS Organizations
into the mix as well. If you’re already
a customer of GuardDuty, you can delegate any account
as your GuardDuty administrator. And then, you can manage up
to 5,000 accounts right from there. The delegated GuardDuty admin account
is granted permission to enable and manage GuardDuty for all accounts
in the organization within that region. The one thing to keep
in mind here, though, is that GuardDuty remains a region
by region service to enable. So you want a GuardDuty
delegated admin account for each region
that you want active. If you enable in US East that’s
the only place it’ll be turned on. However this does allow you
to better control granularity on cost and allows you try out
a region first and then roll out developments
and deployments from there. And as always you can enable
your 30 day free trial of Amazon GuardDuty
with a single click in the AWS management console. I’ve been in the UI meetings
with Andy Jassy where he flat out told us,
one click and one click only. We’ve gotten there
and we’ve worked hard to make this easy
as possible on your end. Okay, let’s move on now
to Firewall Manager. What’s happened here is there’s now
a new set of managed rules and a new version of AWS WAF available for users
of Firewall Manager. Well why does this matter?
Well you can now centrally enable AWS manage rules across accounts
and these rules sets are curated and maintained
by our threat research team. There are also rulesets out there
from AWS Marketplace from customers and partners
if you’d like to go that route. With Firewall Manager
you’re already able to manage your DDOS
protections with AWS Shield, as well as your
VPC security groups all in coordination
with AWS Organizations. We think that adding in
this additional layer of support helps extend your protection
even further. This is another AWS Firewall
Manager and WAFF collaboration. Your logging can now be centralized
under a single account, through Kinesis Data Firehose. Logging in this case,
refers to a list of time stamps AWS resources, WAF actions
and of course request details. We’ve already seen this feature
is making it easier to enable logging across
multiple accounts and web articles through a single firewall
manager policy. We’re happy with
the early returns here and we think you will be too. Another service I love, and I want you to love too,
is Amazon Detective. Detective now has the ability
to analyze IAM role sessions to help you understand
the actions of users and applications that they performed
using assumed roles. So, you can answer questions such as, what API activity
did an EC2 instance perform? And which of my employees
are using a cross account role? By providing answers
to these questions, Detective assists your security
analysts in the diagnosis and understanding of root cause. That means instead
of building custom tools, exporting and storing
and analyzing CloudTrail activity, your staff can start quickly
solving investigative questions. This functionality by the way,
is included at no additional cost. Again our focus is on
your security for customers, we’re always going to bias
towards that. Now, you’ll notice a theme developing
and it’s AWS Organizations. Hopefully, it’s not going to come
as a surprise that AWS Organizations is going to be
at the top of my top 10 list, near the end
of this presentation. Because with security it’s all about
leaning into the power of scale. How can you implement
security efficiently and with less lift
for you and your teams? We think Organizations
is a major step towards both of those goals,
which brings me to IAM Access Analyzer and AWS Organizations,
yes, it’s a mouthful, sure. But access analyzer
uses automated reasoning, a form of mathematical logic
to determine all the possible access paths
allowed by a resource policy. We call these results
provable security and they represent a high level of
assurance for security in the cloud. Some ease of use here, you can enable IAM Access Analyzer
with one click in the IAM console and once enabled Access Analyzer
will generate a report that identifies access
to your resources from outside of your organization. For example, S3 buckets
in your organization that are accessible publicly. This is an extremely handy
little trick and as with GuardDuty
you’re getting insights into your security posture at scale. This allows you to start and finish
a project in the same afternoon, around asks such as, we don’t want any resource
publicly accessible, make it so. Which brings me to Single Sign-On. Single Sign-On is immensely important, because it allows you
to centrally manage access and user permissions in all of your
accounts in AWS Organizations. There have been a number
of SSO upgrades this year from a counter assignment
APIs and AWS CloudFormation support, to automation of multi
account access management. AWS Single Sign-On
is now supporting zero downtime external IdP Certificate rotation. And this should be
a best practice for you to protect against
certificate compromise. How so? Well you generally
want to enforce short lived certificate expiration dates
as a forcing function here, but within that enforcement
you don’t want to be caught in the middle of a rotation
without a cert. So, the zero down timing portion
of the wording here means you can install
a replacement cert while the existing certificate
remains in use. Once again, this comes at zero
additional cost within SSO regions. Extra providers who are also happy
to help in this space include, Okta, OneLogin
and Ping Identity. We’ll round out the identity section
with another certificate upgrade. This one means you can share
a private certificate with any AWS account
or within your organization. Some context here, this means
that customers can manage a private CA in a central account
and use AWS Resource Access Manager to share the certificate authority
with other accounts or organizations where TLS certificates
will be issues. Using Resource Access Manager,
customer can share CAs to an account or organization
at it works with Certificate Manager to allow the designated account
owners to easily provision, manage and deploy
private certificates from a shared private CA. One outcome of this is now AWS CM can automate renewal and deployment
of private certificates, when used
with integrated services. Like elastic load
balancing or API gateway. This feature also provides
APIs to automate the creation and renewal of private certificates
for on premises resources, EC2 incidences and IoT devices,
so it is a really robust feature set. This also eliminates the need
to provision duplicate resources to every account
in a multi account environment, thereby reducing the cost
and complexity of managing resources in every other account. We found historically
that driving down complexity generally leads
to better security outcomes. If you can drive clarity,
the vast, vast majority of people want to do the right thing. The next update is big for both IoT
and audit reports. We’ve expanded the rate limit
for cert requests from 5 per second to 25 per second, which maths out to around
2.1m certificates per day. This provides better security options
for this use cases that require a large number
of certificates in a very short period of time.
Such as manufacturing IoT devices or securing service to service
traffic in a service mesh. We’ve also added support for
encryption of Amazon S3 buckets, which can be leveraged
for certificate verification lists and audit report. Now then, we’re going to talk a lot
more about enclaves coming up. But just in case you don’t have time
to stick around, I wanted to bring
this one up early as well. The reason we’re so excited about AWS Nitro Enclaves
being generally available is now customers can create isolated
computer environments that are unavailable
even to their own staff and use them to protect
personally identifiable information within Amazon EC2 instances. We’re talking about the kind of data
here that involves healthcare, financial services and
intellectual property concerns. The most important and critical
things you can secure today to protect your customers. Again, a much deeper dive on this
coming on later in the presentation. You’ve heard me tout our continued
efforts to decrease any friction or pain points
in your cloud security program. We don’t want overly complex
implementation slowing you down. Nor do we want budgetary decisions
playing a deciding factor in whether
you secure yourself or not. That’s why you’ll see us
regularly lower prices. And this was a pretty big one,
even for us. What this means is Amazon Macie
dashboard has been completely redesigned and features
a price reduction of 80% to 90% depending on the specific
workload in question. We’ve enabling discount
volume tiers to get at any particular size workload and many of our customers
have told us this makes the biggest difference for
them in applying Macie to their work. This price reduction is achieved
by completely rearchitecting Macie’s data discovery engine
to perform even faster
and more scalable detections. Macie is another security service
that features built in native account management
through AWS Organizations. So, again scale
that assists with clarity, ease of use
for single click consoles. And inexpensive security choices. That’s the place we want to be
with our customers. Now, we’re coming down to the end
of our security update, but a few more critical ones
that we’ve hoped you noticed, this one involving AWS Security Hub.
Security Hub has now gone GA and this is a service
we think can give you a comprehensive view of your security
posture across AWS accounts. If setting up CloudWatch events and creating the cross
account permissions is eating up too much of your time, or if your business
has grown overly complex, Security Hub maybe
a simpler solution for you. The Security Hub automated response
and remediation solutions offer predefined response
and remediation actions to common security controls. There are 10 pre-packaged play
books in Security Hub and they’re based on the Center
for Internet Security AWS Foundations Benchmark,
a security standard for AWS resources. Some examples include
applying recommendations that ensure you’ve got
key rotation within 90 days or establish strong
password policies, or perhaps enforcing encryption of
event logs that you stored in AWS. We then iterated by adding
in additional security standards such as PCI and their own
foundational security best practices. There’s also a tabular view
that makes it easier to understand your security posture
relative to the security checks you have enabled in Security Hub. Within Security Hub
you’ll see a visual summary of all of your security checks, as well as account of how many checks
have passed or failed. And because the controls
are grouped by status you can more easily focus
on the failed or disabled controls. You can also filter and search
the controls to pinpoint specific resource types and then sort by using any of
the available table columns. Now this is an example of a better UI that’s meeting you half way
on your security progress. If we tell you that 12 things
aren’t best practices, but then we bury those 12 things
in a list of 100 that you’ve done well,
we’ve done you a disservice. This is an example of how
the Security Hub team is iterating fast, based on customer feedback,
to meet you where you need to be. Our last real critical Security Hub
update, you can now view all Amazon EC2
instances across all your accounts that are non-compliant
with your configured patch rules. In a single dashboard.
AWS Systems Manager Patch Manger, allows you to automatically send
patch compliance findings generated by your patch rules
to AWS Security Hub. This gives you the ability
to centrally monitor your patch compliance
along with other security findings in a single view. Security Hub gives you
a comprehensive view of your security posture across your AWS accounts
and aggregates, organizes and prioritizes your security alerts
or findings for multiple AWS services. Patch Manger is a feature
of AWS Systems Manager. AWS Systems Manager enables
visibility and control of your cloud and on premises infrastructure. Last one here,
Amazon Detective now enables you to examine your Amazon Virtual
Private Cloud network flows. This new capability allows you
to answer questions such as, what port or network service
was in use at that time? Or were any large data
transfers involved? These details help security analysts
investigate findings, examine unexpected network behavior
and identify other AWS resources that might be affected
by a potential security issue. Once enabled, Amazon Detective
automatically processes all the VPC flow records
from your enabled accounts, aggregates them by EC2 instance and the presents visual summaries and
analytics about your network traffic. You can now drill down
into selected time periods to view the details of these flows,
which I highly recommend. So, those were the security features
I wanted to highlight this year, but I know everyone out there
also wants the latest on the newest services,
so let’s get right into that. Here’s a quote from FDR that I find
instructive, “To reach a port we must set sail.”, Sail, not tie an anchor,
sail not drift. This is really where AWS
thrives in my opinion. We don’t drift,
we always have a destination in mind. Even if we know we’ll need to iterate
again and again to meet that goal. And our road map is highly
influenced by customer requests. If you have an idea on something
we can do better on security, don’t hesitate to reach out. That said, here are
the newest security service releases. As promised, I wanted to get deeper
in Nitro Enclaves. Enclaves are isolated computer
environments for sensitive data, featuring cryptographic attestation
to verify that only authorized code is running.
I also want to note here, that we now have a way
to provide encryption for the various IO devices,
storage and networking and the encryption case
can be managed off the main board, with hardware acceleration available
to minimize performance impact. Other important priorities
of Nitro Enclaves, they work on standard nitro
instance types. You can choose the amount
of CPU and memory that is carved from
your virtual private machine. There’s OS agnostic features here
too as both Linux and Windows support hot unplug of CPUs
and memory. This can all be done
via command line as well. Plus you get all of the memory
and side channel protections of a normal virtual machine. The dedicated pinned core,
that’s used for Nitro Enclaves is not shared with the host.
There’s no shared L1 or L2 cache. There’s no memory sharing,
there’s no page coalescing. Essentially the Nitro hypervisor
gets you towards that all important goal
of no human access. Continuing
along this feature set, inside enclaves are standard
operating system boots. This could be a bring your own
Windows license by the way. This gets into a very
technical space very quickly. But going even deeper, Nitro Enclaves
have a read only boot file system. This is about reducing
your attack surface area. We do also provide an open source
and TLS implementation as well as a TCP proxy,
that runs inside the host to allow for secure connections to KMS
and other services. When we talk about
the explicit security that enclaves conveys,
we start with the good image signing and attestation process,
with the KMS services providing a cryptographic pivot point
for outside interaction. A typical workflow here might be
for enclave to use a data key to encrypt external data that can’t
be decrypted by the host itself, it therefore is not
available to your staff. The only way in or out of the enclave
is via a Vsock channel to the host. This also allows for some interesting
public key encryption use cases. As we do offer a public key
enclave via an API call. So, now you’ve got access to massive
amounts of processing power in an isolated computer incident that even your staff
can’t get access to. This is what is so exciting
about nitro enclaves, why I wanted to flag
the general release again today. Next up a product you'll be able
to check out today AWS Audit Manager. I know many of you out there are
operating in highly regulated areas. So we hope this is a new service
that offers you some easy wins. Okay, so what is AWS
Audit Manager? This is a service
that's going to help you access and assess your controls.
In the old manner of auditing you we're often looking
at snapshot audits where you're asked to provide
a report on a certain day. But that's no longer a constraint. Push Button audit reports
are where we need to go with this. You've seen this
with AWS Artifact, that's the ability to get attestation
of compliance about our controls, the things we operate
with AWS Audit Manager, you're now looking
at your own environment, and with the ability to prove
compliance against regulations that you are subject to,
from your own systems, At AWS in meetings for project
will often ask so what do you get for this, you know,
what's the win for customers here. So the key customer problems
we're looking to solve here are manual and time consuming
audit evidence collection. You're gathering screenshots
or logs across configurations. And then just for fun,
you're also organizing it in a way that makes sense. Because you can't just hand off
1000 pages of logs to an auditor and say good luck, have a nice day. You have to show how your business
is enforcing controls around data retention,
or encryption or access control. Or maybe you need to prove
that you're prohibiting direct access between credit cardholder data,
and the internet to align with PCI. Regardless of your individual
compliance use cases, AWS Audit Manager
continuously collects evidence, helping you ensure
your controls work as intended, so you can proactively
manage and reduce risk. Under the hood, the service
is gathering evidence based on pre-built
or custom assessment frameworks that determine what evidence from
which resources should be collected. You'll see we're launching
with CIS, GDPR and PCI here with partners such as Algress,
CIS, Coalfire, Deloitte, Jacoby Engineering,
Smartronics, and TeleTech. So what are some use cases here? Well, you can move from manually
managing evidence in spreadsheets to an automated
evidence collection method. That's first off, you can now
continuously collect evidence, monitor your compliance posture
against a desired state, and proactively reduce risk by
introducing or fine tuning controls. And lastly, if you need
to perform risk assessments, we think it's a great place
for the service to help you. In addition
to the pre-built frameworks I just mentioned, you can also build
your own assessments as well. To get started,
go to the management console and activate Audit Manager,
you can then choose one of the pre-built assessments
that I just mentioned, or you can build your own. You'll then delegate evidence review
to the appropriate stakeholders. Once you've done a sanity check
on the inputs and the outputs, you're then ready to look at
the reporting side of audit manager. We want this to be simple. So this is the runbook.
Please give it a try. Let us know what's working for you where we can go
for future feature set. We have Fiona Williams,
Deloitte AWS Alliance Lead and former CISO
joining us on a call today, Fiona Welcome and thank you, I know
you've been engaged with the AWS Audit Manager beta? What are your thoughts about
the benefits of this service, and what it brings to our customers? Thanks for having me, Steve, and I'm thrilled to discuss
Audit Manager, which I believe should help
technology professionals and auditors improve the efficiency
of their audits. The cloud is the new normal,
and many organizations want to move to the cloud
at an even faster pace. Often that speed is impacted by
concerns about security and controls which sometimes
can be a blocker for companies to move workloads
to the cloud. And for organizations
to test their controls and confirm
that they're adequate, they need to rethink how they do
that, as traditional audit practices don't scale to dynamic
cloud environments, audit management
helps companies address this by proactively collecting
relevant audit and control evidence from a cloud environment. And because it's a cloud
native service, it allows customers
to get started quickly and to scale as the business
and cloud usage grows. Thank you, Fiona, can you expand
a bit on how AWS Audit Manager helps solve the common challenges arising from
traditional audit practices applied to cloud environments? There are three features
that I really like, it should help to make audits of the
cloud more efficient and effective. The first is the predefined
assessment templates. These templates are based
on industry standards, such as CIS, HIPAA,
PCI and High Trust to name a few. And they should allow you
to accelerate the development of your own testing templates. These can be customized,
you can add your own custom controls and add your own custom
templates based on what your audit requirements are. The second feature, and probably
the biggest time saver is the automatic collection
of audit data. So instead of manually reviewing
and collecting audit data, the system automatically
does that for you. It continuously gathers
and tracks control data from sources such as CloudTrail, CloudWatch, Security Hub,
and Config. So it's doing continuous monitoring
and gathering of data, rather than at a point in time. And finally, the built in workflow. This allows auditors to add
comments to collaborate to document their reviews
to delegate tasks during the audit. And one of these features
I think will help you deliver a more efficient
and effective audit. Thanks, Fiona, we really
appreciate your time today. Okay, continuing along
the audit front, I'm really excited to feature
a new training program that we've launched, AWS
Cloud Audit Academy. So what is Cloud Audit Academy? Well, basically, this is
a training curriculum for audit risk
and compliance professionals, that narrows in scope as you
progress through the training, starting with cloud as a concept
across the general industry, all the way down to the specifics
on how to audit AWS, and industry specific components
about auditing the cloud. Here's some of the topics
the Cloud Audit Academy gets into. None of these
are going to be shocking. These are the building blocks
of any security program. And both levels of training
are aligned to the GDPR privacy directive, as well as global industry security
and compliance domains such as the Cloud Security
Alliance controls matrix, ISO 27,001, NIST 853,
and SOC 1 and SOC 2. As you can see, there's
a comprehensive list of topics within the security compliance
and privacy domains here. And in the grand tradition
of AWS training, there's something for everyone. It's meant to be a deep dive
for your folks in compliance to understand how their work
interacts with the cloud. Clearly automating is one of
the last spaces out there where there are still
people doing work that should have been
optimized for them. The benefits of the cloud
are massive for security, but we want to see those wins
conveyed here too. And both AWS Audit Manager and the AWS Cloud Audit Academy
are steps in that direction. In terms of levels,
you can choose both e-learning and instructor led training format. Attendees can receive continuing
professional education units for these as well. And you can see on screen that we've
got some levels within the levels. Within e-learning and in person, there's also a breakout
among general cloud auditing versus AWS specific. I should also mention that any in
person training would of course, be incumbent on us
being able to offer this in a manner that's safe
for our customers. We've taken a lot of steps
internal to AWS and Amazon at large
in terms of safety. And so we've learned
a lot and clearly, we won't be getting back
to in-person instructor led training until it works completely
for our customers and our staff. To learn more head
to our compliance page, and then to the auditor
learning path. We look forward to working
with you in this critical space. Okay, next on to the new services that we've got going on
with AWS Network Firewall. First up, here's how it works
within the context of your overall security services. This is a native firewall service
that allows you to apply blanket protections
for your entire VPC, regardless of the application
type or protocol. This means AWS Network Firewall
gives you control and visibility across both the network
and application layer. Crucially, Network Firewall allows you to broadly inspect traffic
flows to and from your VPC and also over the internet
and over Direct Connect and VPN we’ve got all the different
network paths covered. From a technical perspective, AWS
Network Firewall is a zonal service consisting of AZ
isolated inspection points. The critical things here for
customers is it's managed by AWS, features load balancing, and has
zonal symmetric flow forwarding. From a customer point of view, the main thing that you want
to pay attention to is your endpoint policies. We're managing the fleet of EC2
host for you, including failover and auto scaling,
we're maintaining OS updates, and the other work
that you would have to do if you are maintaining
your own firewall. Going a bit deeper into
those cloud native controls. IP port and protocol gives you
baseline segmentation capabilities with the ability
to allow or deny traffic based on the domain name
of the destination, instead of an IP address. Furthermore, the service
has a stateful inspection engine that allows you to defend
against common network threats such as malware intrusion
and protocol abuse. You can also do things like identify
if encrypted traffic is trying
to leave through a port that's typically reserved
for unencrypted traffic. Lastly, you can choose to allow flows
through drop unauthorized flows, or simply observe traffic patterns
by using the alert action. So the tool set is very much aligned with a practical application
of real security. This service is available now
we've got a few of the benefits listed here on the slide.
In terms of network security. This makes it easy
to deploy protection at scale across your Amazon Virtual
Private Clouds. Network Firewall
is also a managed service that scales with network traffic and can support hundreds of thousands
of connections at the same time. Finally, it comes with a highly
flexible rules engine that supports thousands of customer
rules for intrusion prevention, detection and web filtering. And it's all native
to your cloud environment. Once again, this is going to be
an easy implementation. If you'd like to try it out,
you can find AWS Network Firewall and the Amazon VPC console. From there you'll have a number
of options around your policies as well as the places
that you want the service active. Okay, so those are the big
announcements that I've got for you today
on the topic of security. But we've got a bit more time
to get into the strategy of security before we end the session
with some best practices, we'd like you to consider. Zero trust is a term you hear
often these days. And Zero Trust can mean different
things in different contexts. One key reason
there's so much ambiguity is the diversity of use cases
to which it applies. Here's a quote from Alvin Toffler
on the need to focus on the smaller things
in order to do big things. Toffler, by the way, was the person who coined
the term information overload. So he clearly would want this section
to be efficient and full of clarity. Just from a definition standpoint,
Zero Trust is, to me, a set of mechanisms that focus
on providing security controls around digital access,
and assets, while not solely depending
on traditional network controls, or network perimeters. In other words,
we aren't going to trust a user based only on their location
within a traditional network. Instead, we want to augment network
centric models with additional techniques, which we would describe
as identity centric controls. Now, keep in mind that another
primary concept of Zero Trust is it should include attributes
such as usability and flexibility. We all know that you can secure
a safe at the bottom of the ocean if you put in a block of concrete. But it's not a very usable tool
at that point is it? In terms of the keys to Zero Trust,
let's look at two key dimensions. The first being the network itself, you're always going to have some
notion of a perimeter in security, the thing that surrounds
the thing you're protecting, or the things it may be
more than one. For example, in many scenarios,
a proxy is trusted, in part,
based on its network properties. Most of the time,
people are designing systems so that traffic from specific
internal IPs is considered trusted. Or maybe you have a set of containers
on the same host running as part of the same application
deployed by a single Dev Ops team. And that's within
a trusted perimeter. So the question becomes,
where is my perimeter? How big or small is it? And you should make it
as small as possible. And how easy is it
to monitor an audit? And in terms of effectiveness
and user interface, should we use a VPN
for network isolation, but make it dynamic and hidden
from the user experience, so that users don't even notice
that network boundaries are being created
and torn down as needed? Or perhaps we break systems down
into even smaller logical components and go with tighter network segments or even packet level controls
around some applications? What we consider micro segments
or micro perimeters, do we add in some kind of
a gateway or proxy technology that enforces a newer kind
of a trust boundary down the road? How about a combination
of those techniques? And if those are the questions
that come up when you're securing your network, a second consideration is always
identity and access management. This again runs the gamut
of use cases from humans with PCs
or tablets or phones, to machine to machine or software
to software communication. across those types of use cases, we can see that identity
authentication and authorization techniques can be much more different
in practice, right? People don't talk to machines
the same way that software talks to machines. And this leaves us with open
questions around how to secure. Should we organize around
security relevant properties of the end user profile,
or maybe we want to alter access dynamically through
some other factors, such as the strength
of the authentication, the device type,
the network location, the time of day, day of week, etc. Now then, identity centric perimeters
can be used to interact with AWS API endpoints,
and they uniquely authenticate and authorize each API request. However, network centric tools
such as Amazon Virtual Private Cloud, security groups, PrivateLink and VPC
endpoints are also easy to implement, to filter out unnecessary noise, which allows your
security inspection services and your staff to focus on just
the components that are important. But really what we want is
for these two types of controls to not only coexist but be aware
of and augment one another. A real world example here is VPC endpoints provide the ability
to attach a policy to enforce identity centric rules
at a logical network boundary. So the two concepts,
network and identity share the same underlying principles
even if they differ in what they're trying
to achieve for an organization. We want to focus on the problem
we're trying to solve because Zero Trust can mean different
things in different contexts. One key reason
there's so much ambiguity and confusion around the term might be the diversity of use cases
to which it applies. But by focusing on the problem
you're trying to solve, we'll spend our time improving
security posture and outcomes, and avoid getting mired
in low value discussions. One of the discussions we have
in Amazon quite frequently is around not trying to solve the entirety
of the problem will at once. And I'll tell my teams give me
an 80% solution right now. And let's iterate
towards the final outcome. The same is true here,
constant steps of improvement. We believe it's best to think
of Zero Trust concepts as additive to existing security
controls and concepts really, rather than replacements.
Because one size does not fit all. We want to focus
on the value of the systems and the data
that are being protected. Over time, the application
of a Zero Trust conceptual model will continue to improve
defense in depth and continue to make
security controls we already have, work better. Use Zero Trust concepts
to raise your security bar, but don't issue blanket standards
that lack flexibility. For many business systems, network
controls and network perimeters will continue to be important
and sometimes adequate controls. If we begin to look at the three
use cases I just referenced, the first is to consider machine
to machine communications. This is about authorizing specific
flows between components to eliminate
lateral network mobility risk. Basically, if two components
don't need to talk to one another across the network,
they shouldn't be able to talk, even if those systems
happen to coexist within the same network
or network segment. This greatly reduces the overall
surface area of connected systems and eliminates unnecessary
or unneeded pathways that an adversary
might take advantage of, particularly those that lead
to sensitive data. For this use case, our discussion
should begin with security groups, which have been a part
of Amazon EC2 since it launched. The point of security groups is to provide software
defined micro perimeters. They also act as a kind
of identity system which group membership
becomes relevant for determining whether or not to permit
a particular network flow. Allowing for extremely granular rules
without the burden of keeping them up to date as membership
in the group ebbs and flows. Another way to get at this
would be AWS PrivateLink. Using PrivateLink, a load balanced
endpoints can be exposed as a narrow one way gateway
between two VPCs. With tight identity based controls
on who can access the gateway, as well as where
any incoming packets can land. VPC's don't even need to have routes
between one another so the outcome here is going to be robust machine
to machine network security. Our second Zero Trust use case
human to application is about improving workforce mobility
without compromising security. Right now, especially with higher
levels of work from home this is one that's clearly
on everybody's mind. Now traditionally,
these applications existed behind a strong VPN front door.
However, VPNs aren't always compatible with the full range of mobile devices
that modern workforces leverage. So the objective here is to make
the locks on applications effective. Enough that we can eliminate
a VPN based front door altogether. Depending on your risk tolerance
and developer maturity, there are a lot of options out there. At one end of the spectrum,
you may want a desktop as a service, which we offer as AWS Workspaces.
Or you prefer an end user application as a service product like AWS
AppStream. Once you've got into that place,
traditional security controls are then applied
to the intermediary services. So a user with a PC
or an HTML5 client can reach virtualized
applications over the internet. Now you've got a desktop
like experience, without having to worry
about the security of the final device
in the user’s hands. On the other end of the spectrum
is connecting internal web applications directly
to the internet. For this, we recommend
a combination of AWS Shield, AWS WAF,
and Application Load Balancer. Going down the line
that would be leveraging AWS Shield for a managed DDoS
protection service, AWS WAF
as a web application firewall, and then authentication through
the application load balancer in order to integrate
with an identity provider to offload the work
of authenticating your users. Using this combination, your internal
custom applications quickly become just as flexible as
software as a service applications. Allowing your workforce to enjoy
the same from a coffee shop flexibility, while unifying
your application portfolio under a common security model. And finally, our third Zero Trust
use case which is markedly different
from the first two because it involves securing digital
transformation projects such as IoT. This could be a connected vehicle
use case where a car needs to relay a stream of instrumentation
data over the Internet to a cloud based
analytics environment. Historically, these types
of workloads have always existed entirely outside the traditional
enterprise network. So they require a security model that accounts for that
particular situation. Here's where you want to use services that can issue
unique device identities to every device in your fleet,
and then use those identities and associated access policies
to securely control how they communicate
and interact with the cloud. And of course, I'm recommending
services like that. But I'm also recommending
you take a look at our IoT device defender service.
But sales recommendations aside, we do think this use case
will continue to expand as we see more workloads move closer
to the edge to minimize latency and to improve user experiences. So to wrap this topic up, what I really like
to see security practitioners focusing on the principles
of Zero Trust, that increase your security posture. Don't segment out your identity
and network security, instead make them complimentary. Your control should coexist
and augment each other. And then it's about
the use case itself. Is it machine to machine?
Are humans involved? Is it IoT? This is going to be where you're
making security decisions that are appropriate for the things
you are trying to protect against and to protect. And lastly, something we always
advocate for is AWS, don't put inflexible
mandates in place, give yourself and your team room to grow with the technology
that's out there. Okay, as we near the end, here,
we've had a lot of success last year with a list that we published
around the top 10 places your security group
should focus. So I want to revisit that concept
again today with a refresher. Excellence is to do a common thing
in an uncommon way. For security, that means fighting
for each inch or centimeter, and really knowing your environment. So taking a list like
I'm about to present you and doing a few of them,
gets you a few wins. But there are a lot of themes
and tactical things you can do to put yourself
in an excellent position for 2021. That might be the uncommon action,
you should commit to today really doubling down on your security
mechanisms to make this guidance, something that
has actual tactical impact. Before we move on to this
year's recommendations, I wanted to take you
back to 2019s list because these are still relevant, and they aren't items
that you can now ignore. So if this is your first time
seeing one of these security lists, you may now have 20 things to do.
Hey, let’s reinvent, this is awesome. You can expect the security advice
to be prolific from a company that takes it as seriously as we do. Seriously, everyone do take note
of these if you haven't seen them before. And if you did take action
on these items last year, maybe take some time and reconfirm you're still
in a great place in these areas. And now on for our new top 10. We noted them this year
as strategic versus tactical. Clearly the strategic ones might
require a bit more introspection, more planning, more time,
and the tactical items feature things that you can begin
implementing today. So let's take a look
at each one of these right now. I've mentioned it a few times
already we think AWS Organizations is a place you can really pick up
some security wins at scale. Because it's a place
you can configure centrally, you're going to gain
a lot more ability to rapidly up level your environment. Organizations has a feature
called service control policies, that will make your life better. For all of the accounts
you have in Organizations, you can use these policies
to do great things like prevent deletion
or modification of IAM rules, prevent tampering with CloudTrail,
and prevent public S3 access. In this sense,
you're replacing reactive controls with preventative and proactive ones. And that's a place
we want your security posture to be. Next up, deeply understand
your environment. This is very close to something
I mentioned last year. Your monitoring shouldn't just be for
when a bad thing happened. Instead, you can use tools
like Security Hub, which is of course compatible
with Organizations to implement a set of standards
across like PCI or CIS and output a security score
and identify the specific accounts and resources
that require your attention. It is impossible to improve upon
something without measuring it first. When you've got a security score,
you can then, as a business, decide how to improve that score. Or if you're okay
with any security tradeoffs you might have made
when building your systems and tools. Now, you've heard the buzzword
and phrasing around, just encrypt everything. And the reason you hear that
is because oftentimes, it is the last line of defense
against an adversary. If all else fails, data
that's improperly accessed can still be protected via encryption,
if done properly. We've got a few tools to help you
that are listed on the screen here. And none of these should look
entirely surprising to you. Our KMS service is now integrated with
the vast majority of our services including GuardDuty Macie
and Certificate Manager. And of course, at the very minimum,
you need to have a robust encryption plan
for your sensitive storage. We offer a huge array of options
on encryption for data at rest, in motion,
where you're able to maintain the key and only allow access to the users
you specifically choose and prove
who has had access over time. Next up Federation. This can be handled through our AWS
security token service or STS, where you're granting
temporary limited privileged credentials with IAM
for authentication. STS also has CloudTrail support, so you're then logging all of
your calls for access as well. You're getting the time,
the ID and the access requested so that you've got a record of
potentially abnormal access requests. I spoke about Zero Trust earlier. And this is a building block
for Zero Trust because 100% knowledge
of your environment, in other words knowing
what you're protecting, is the foundational basis to establishing
a Zero Trust environment. Another quick win here
is AWS Single Sign On. From a single portal,
you're centrally managing access across accounts and applications. Your users have access to the things
they need access to which they like, but they don't have access
to the part of the business they shouldn't have access to which
surely your security team will like. You can assign user permissions
based on common job functions and customize these permissions to meet your specific
security requirements. And this isn't even about AWS. Our SSO also includes built
in integrations to Salesforce, Box and Office 365. Or you can create
and manage user identities in AWS SSOs identity store. Or easily connect
your existing identity source, including Microsoft Active Directory,
and Okta Universal Directory, and Azure Active Directory
or Azure AD. I mentioned exactly how to do
this earlier through Organizations, but you can also handle
this through S3 itself with our block
public access feature. So there's really not
a good reason anymore to be caught unaware
by public access. We've made it a space where
we explicitly want you to choose if you want your storage
buckets open to the world, we closed them by default,
when you establish the bucket. You are secure by default. New buckets and access points
don't allow public access. So this is about having
yet another confirmation and another audit point
in this area. If you do absolutely have
to serve public content, do that from a small number
of specifically chosen and exempted buckets. Do not make it a blanket thing.
I cannot stress this one enough. We hear the term edge protection
thrown around a lot, but this is just another term
for those technologies and applications that are near
to the internet in your architecture. That's why you often hear IoT
and edge protection the same sentence because a single
transmitter device is considered to be the edge
of your protected network. Which means the tools here are the ones on
the front lines of security. And services such
as Amazon CloudFront, WAF, and API gateway are the easiest ways
to get at this type of protection. CloudFront is a content delivery
network that companies like Hulu or Slack, Prime Video and PBS
all use to deliver content. So it's going to be a robust solution
with considerable security baked in. I've listed the threat
dashboard as a feature here because you no longer need
Shield Advanced to access this, you can see a near real time
summary of the AWS threat landscape through the shield console itself,
by going to global threat dashboard. It's definitely worth a look. We've also published
a threat landscape report with an all up analysis
by time period, size, type and so on. Our seventh recommendation today,
please, please, please consider automating
your patching program. This can be accomplished
via AWS Systems Manager, and building it in to AWS CodeBuild
using a code pipeline. There are entire blogs, white papers
and videos dedicated to how to set this up
in your environment, including one
that's jazzily titled, AWS prescriptive guidance automated
patching for non-immutable instances using AWS Systems Manager.
So I won't belabor the point. But I will ask you to look into
how you do this today. Because patching your systems
are security vegetables, you may not like it,
but you have to do it. Now this one, in contrast,
is more philosophical and strategic. So it's a place you want to dedicate
some resources to long term, as opposed to a set it and forget
it kind of security control. What we're getting at here
is multi layered defense. And there are Zero Trust concepts
in this one as well. But essentially, it does you no good
to have a robust firewall system without encryption.
It's not effective to require a VPN, but then allow your user base
to access PII, no matter what the role, and so on. What you don't want is the idea
of a coconut with a hard shell, but a soft and tasty inside. Make things difficult
on potential adversaries don't rely on just one
or two controls. This one's a lot
for one little slide. But again, it's more about a way
of operating and security as opposed to something
tactical right this minute. This guidance comes about
because we often have conversations with customers
on how we do security to AWS. Well, these are
some of our key concepts. We're making sure leadership
is aware of security projects
and opportunities. every single week.
Everyone from our CEO down is deeply aware of the places
we want to improve, as well as why we feel that way. We're never a blocker
in the security team for speed. Instead, we want to be
the group that works with teams to make security easier
and more efficient for them. And I think the first one here
is critically important, be optimistic and accountable. It's really easy to get caught up
in a headline about security
where something went wrong. Or when a number of things went
wrong to create one big mess. But what you don't see are
the trillions of distinct activities and decisions that are going
right each and every day. There is simply no way to measure
just how much positive goodness is happening around us
all the time. You're watching Netflix
while you're on your phone, and you get a Slack notification. So many untold hours of work have
gone into that one quick scenario to make all of our lives better. And as you're doing all that
it's almost always going to be 100% right and in a secure manner. The bad days are outliers,
they're not the norm. But with that comes accountability. When things do go wrong, own them
and make the decision to do better. That's really our daily task
and security, get a little bit better at our jobs, about protecting our customers
every single day. Get a little smarter.
And that's where root cause comes in. Whenever you see something
is not quite right, the solution isn't just to fix it.
Fixing it makes it go away, but it may not lead to the eventual
outcome that you want. Instead, figure out why things
are happening in your environment. That's the sort of activity
that can pay huge dividends when you solve
the true root problem. The last thing I want
to highlight today is diversity in hiring
and training. This is a space
that I'm passionate about. I fundamentally believe that
a broad range of perspectives makes us far better as an industry. We must reflect the communities
that we serve. We often see the new and creative
thought comes from places that aren't thinking alike
where group think hasn't set in. The other part of this is
about having a training program that allows for security engineers
to be created internally. The shortage for security personnel
is projected to hit over 3 million people
in the next decade, there aren't going to be enough
people studying this discipline, for us to make up that gap
with college graduates alone. So we need to do it
with the talent that we have. If you have customer service people
or physical security personnel, or really any other
operational domain, where your people are showing
drive and aptitude, have a pathway
to security engineer for them. Invest in robust training
for the employees who already embody your culture. External hires in this area
are competitive and time consuming. So we're in the process
of implementing multiple pathways to security engineering
for our people internally. These are great jobs with a lot
of autonomy and creativity. We've got to show people
the way to get there first. People want to do the right thing. And they want to be helpful
in the realm of security. It's up to us to support
the transition. So that's our session for today. I want to thank everyone
for listening and I hope I've given you a few items you can take back
to your work and implement. You can follow me on twitter
at @Steven Schmidt. I post there every so often
with my take on security. That said I hope you have a safe
and secure day you enjoy the rest of re:Invent. The security track has a bunch
of great offerings this year. So please do check out
a few more security sessions if you've got the time.
Thank you everyone. Please make sure you complete
the session survey. [music playing]
