Strong Security Made Simple

The cloud simplifies security.

The cloud simplifies security.

* When you understand how it works
** Compared to traditional environments
*** Depending on how much you pay attention to this talk😉

The goal is cybersecurity is actually quite simple...

To make sure that systems work as intended...and only as intended.

The Shared Responsibility Model

This model dictates how operations work in the cloud, and that includes security. The model itself is simple but—as always—the devil is in the details.

On-premises, you are responsible for daily work in all six areas: physical, infrastructure, virtualization, operating system, application, and data.

Right away in the cloud, half of the responsibilities are delegated to the cloud provider. And as you move towards managed services, you delegate more and more. This has a major security and business advantage.

In all cases, you are responsible for the configuration of the services you use and the data you process and store in those services.

Being a paranoid, tinfoil hat wearing security professional, I'm not asking you to simply take the cloud provider at their word. You have to verify they are fulfilling their responsibilities under this model.

The way you verify that work is through compliance attestations. For AWS, simply visit https://aws.amazon.com/compliance/.

There, you'll be greeting be logo soup. Most of these compliance frameworks are hyper-specific and apply only to a narrow vertical or geographic location. Things like SOC1—3, PCI DSS, ISO 27001, ISO 27017, and ISO 27018 are more broadly applicable.

For direct evidence of this work, check AWS Artifact. It's a "service" that allows you to download the auditors report for various compliance frameworks.

This is an odd service for a number of reasons. Mainly because it's just one web page with a whole lot of buttons. Another reason is because it's the only AWS service that doesn't have an API. It's still extremely useful in the narrow use cases it support and it's available now in your AWS Management Console.

When you map the division of responsibilities between you and AWS, here's the trend lines.

The more you move to the right, the less responsibility you have for running your builds. This means you can focus on delivering business value.

The reason is simple. AWS is doing more. You do less.

That applies for operations and security.

What's stopping us?

Are hackers stopping us?

Is the threat of being targeted by hackers slowing down your security team? Your business? Are you so focused on stopping these attacks, that you're not seeing what's right in front of you?

Does every security team meeting include a mention of two specific nation states?

When you evaluate a threat model, are most of the mitigations designed to stop targeted attacks from a nation state actor?

Unless you are a nation state actor, you are wasting time and energy.

Maybe you're more introspective...

Are you worried about threats from employees? From users with authorized access? Insider threats are massively overrated.

Most threat models treat insider threats as people with access that have malicious intent. This intent combined with insider knowledge can be catastrophic...but it's also rare. Very rare.

Stop.

Beyond a doubt, the biggest threat to your builds is your team making simple mistakes and misconfiguring various cloud services.

If your threat model doesn't address this as the top threat. It's wrong.

Yes. Wrong.

You cybersecurity goal is simple. Make sure that the systems you build work as intended and only as intended.

The biggest risk to that goal? Mistakes and misconfigurations.

Can I learn from others?

The AWS Cloud Adoption Framework is divided into six perspectives. Each of these perspectives helps you identify stakeholders, processes, and other business impacts.

• Business
• People
• Governance
• Platform
• Security
• Operations

Working through the framework under each of these perspectives helps you build an action plan.

This action plan is the road map for your business as it moves to the cloud. Security is an integral part of that. It's woven into the fabric of everything you do (at least now it will be, right?)

The AWS Well-Architected Framework is constructed with 5 pillars. Each of these pillars is implemented in the technical aspects of your build.

• Operational Excellence
• Security
• Reliability
• Performance Efficiency
• Cost Optimization

Taken as a whole, the AWS Well-Architected Framework helps you make smarter technical decisions.

The framework helps you strike the right balance for your business needs at any point in time. It also instills a number of habits that help make sure your builds continue to stay in line with your priorities.

AWS has listed a set of attributes that make up Modern Application Design.

Modern applications are:

• Secure
• Resilient
• Elastic
• Modular
• Automated
• Interoperable

But most organizations are dealing with a host of existing applications. They may or may not exhibit the attributes of a modern application.

AWS suggest four approaches to modernizing your application:

• Re-host >> move as-is
• Re-platform >> adjust the operating system or other underlying pieces
• Re-factor >> start to break up into microservices
• Re-invent >> start again with a purely cloud native approach

The CIS AWS Foundations Benchmark also provides a great starting point.

This benchmark was built from a consensus of expert opinions on some basic AWS configurations that focus on security. This benchmark is written in a checklist format and is very easy to apply.

AWS Security Hub makes it easy to monitor your progress against this baseline.

What Happened?

Traditionally, auditing has played a big role in a security team's area of responsibility. Unfortunately, auditing has also gotten a really bad name.

At it's heart, auditing is an attempt to keep process at a high level and to be able to provide an answer when someone asks, "What happened?"

AWS CloudTrail is at the heart of auditing and monitoring in the AWS Cloud.

CloudTrial provides a list of what happened and—critically—who or what made it happen.

CloudTrail maintains an audit trail of almost every activity that takes place in your AWS account in an S3 bucket. The logs are written to this bucket about 2-4m after an event takes place.

There's no guaranteed delivery time for CloudTrail logs, the 2-4m is based on general experience across what I've heard from AWS engineers and customers around the world.

These logs are used as the primary data source for a number of other AWS Services and are easily accessible by you and your team.

Who's there?

The second security question in the AWS Cloud centers around identity.

Understanding who (or what) is taking action within your environment (authentication) and what they are able to do (authorization) are critical to a strong security posture.

The underlying principle here is called "the principle of least privilege". This means only giving a entity (who or what) the permissions required to do what they need to and no more.

AWS makes this easy but also tempts you to break it.

AWS Identity and Access Management (IAM) is a global service (it's not region specific) that underpins identity within the AWS Cloud

This service provides the ability to create users or roles and assign them permissions to various AWS services.

AWS IAM provides a set of tools to help manage authentication and authorization.

Every service in the AWS Cloud supports IAM (with only a few edge cases). IAM is an extremely granular layer for implementing the principle of least privilege.

IAM policies can be written from scratch or you can use any one of the number of managed AWS policies. This is where AWS tempts you break the principle of least privilege by providing *FullAccess policies. Don't use these in production!

Additionally, you don't have to recreate your users in IAM as numerous options exist to connect (federate) with your existing directories.

There is a bit of an art to managing policies (beyond not using *FullAccess). You can assign them directly to each user. That'll work but there is a simpler, more scalable way.

Using a Role and having a user assume that role (putting on that hat), makes it easier to manage permissions.

Setting up a "StorageManager" role and a "BuildManager" role make it easier for users to assume those permissions when completing those specific tasks.

When they aren't doing those tasks, they don't have those permissions. This provides a clearer audit trail and makes sure that you don't accidentally take an action when it wasn't intended.

As with anything, the devil is in the details. IAM appears simple but it can quickly scale out of control.

Here are some additional resousrces to get you started:

• SEC209, Getting started with AWS Identity here at AWS re:Invent 2019
• SEC310, Access control confidence: Grant the right access to the right things here at AWS re:Invent 2019
• the IAM Best Practices website

How can I protect my network?

Amazon VPC, virtual private cloud, your own slice of the AWS Cloud.

A VPC provides controllable routing, IP space, subnetting, and access control at the network layer. AWS enforces this through this infrastructure. You can configure the network just like any other.

VPC Endpoints provide a private and secure method of connecting to other AWS services from within your VPC instead of connecting over the internet.

AWS PrivateLink offers the same capability but to 3rd party SaaS services hosted on AWS. Finally, AWS Direct Connect creates a dedicated network connection from an on-premises environment into the AWS Cloud.

AWS Transit Gateway is a relatively new service that greatly simplifies complex network design in the AWS Cloud.

Before this service, if you wanted to connect a number of VPCs and traditional environments, you had to jump through a number of technical hoops to get things working.

Now, AWS Transit Gateway makes it easier to connect these separate elements through simple configurations. It basically reduces the complexity of your network configuration by an order of magnitude...or two.

From a security perspective, all of these elements basically answer the question, "Is A allowed to talk to B?"

That is part of the security equation, but only part of it.

This is where you should investigate using another type of security control. An intrusion prevention system (IPS) will actually look at what A & B are saying to each other.

Is that traffic malformed? Malicious? Otherwise harmful?

The answers to those questions are really important. An IPS can help you find out.

How do I protect compute?

The AWS Compute services help run your code in the cloud.

Using the lens of the shared responsibility model, here's how the AWS Compute services align.

While Amazon EC2 and AWS Lambda are crystal clear on either end of the responsibility spectrum.

Things getting a little muddier with Amazon ECS and AWS Fargate. Just remember, that ECS is a platform designed to help you run your containers, where Fargate is an AWS platform that runs your containers.

That's why you have more responsibilities when it comes to securing ECS (which you then essentially treat as more EC2 instances).

For Amazon EC2 and Amazon ECS, you should focus on:

• Hardening the OS configuration
• Adding controls like integrity monitoring, intrusion prevention, application cnotrol, anti-malware, and the like
• Don't patch or log in to production, fix issues upstream (systems over people!)

For AWS Fargate and AWS Lambda:

• Code quality is the top priority
• Real-time application protection controls can be of help
• Dependency verification and validation is critical (check those open source libraries you're using!)

For all forms of compute, some general security principles to keep in mind:

• Fix issues in the build pipeline and then redeploy (blue/green deployments). Systems over people!
• Automate the deployment and configuration of security controls. Include security in your code and integration tests
• Builder's workstations are a weak point. OpSec is critical
• Keep looking for areas where people are doing repetitive work and use a system there instead. Systems over people!

How do I protect my data?

AWS has a number of database services (10 foundation services and counting, here's my take of them). These vary in database type and level of management provided.

Your primary security concerns here are understanding what your data is and where it is, along with:

• Encrypting the data at rest—which is usually a simple checkbox along side an encryption key configuration
• Using IAM to restrict the access to the data
• Backing things up regularly and testing those backups!

AWS also offers a number of services where you can store data. These range from file systems to bulk storage. Each has a place and a specific operational concerns.

In general, your primary security concerns here are the same as with the AWS Databases. Understanding what your data is and where it is, along with:

• Encrypting the data at rest—which is usually a simple checkbox along side an encryption key configuration
• Using IAM to restrict the access to the data
• Using lifecycle strategies that balance cost with reliability and availability

Is this working?

Observability is really an umbrella term that covers monitoring, observability, traceability, and anything else that looks to answer our question, "Is this working?"

Traceability's formal definition is a tad boring. To, "verify the history, location, and application of a specific data point or action"

...really that means answering these questions:

• Where did this come from?
• Who can access it?
• When?

The same thing applies to the formal definition of observability. It's stuffy and doesn't really drive the point home.

At it's core, observability simple means asking, "Whats going on?"

AWS X-Ray is a distributed tracing service. This service helps you track requests through your application and measure response times, spot issues, failures, etc.

From a security point of view, X-Ray provides cross-service visibility (which is huge) and helps map out your AWS service usage.

Support is somewhat limited but getting better all the time. Like here at AWS re:Invent 2019, when we're sure to see some significant enhancements.

Amazon CloudWatch is a service that monitors various metrics, events, and logs.

One of the challenges with this service is that it's really 3 services disguised as one. Metrics, events, and logs are actually 3 distinct parts of this service with a bit of crossover.

Metrics are useful for basic operational health (bandwidth consumed, CPU percentage in use, etc.). Logs are excellent for collecting and monitoring system and application events.

While CloudWatch Events is the hidden gem that provides an excellent starting point for an automation practice by connecting those events to AWS Lambda functions.

Leveraging two services that we've discussed, CloudTrail and CloudWatch Events, allows us to create an automation practice with two primary work flows.

The first uses the fast lane provided by CloudWatch Events triggering AWS Lambda functions. This flow is perfect for anything that requires a rapid response.

The second work flow is the slow lane. It's backed by CloudTrail (with it's 2-4m delivery time) which triggers AWS Lambda functions via Amazon S3 (where CloudTrail stores it's logs). This is an excellent solution for any security need where time is not the most critical factor.

Keys to success

The cloud simplifies security.

By sharing those responsibilities with AWS, you can focus on fewer areas where you should see more impact.

The key is understanding the line between those responsibilities. What is yours and what is AWS'?

This leads to a natural push towards more managed services. Traditionally security teams shied away from these types of offerings. That's a mistake, you should be driving your organization towards them. They are big security win.

The keys to successful security in the cloud are:

• Have a plan. The AWS Cloud Adoption Framework can help
• Build well. The AWS Well-Architected Framework can help
• Choose systems over people. Use the right controls and tools to do less and get more
• Observe & react. Nothing is ever "done". Keep monitoring what's happening, adjust, and continue to monitor

Thank you!