Updating Your Security Practice for the Cloud, Step-by-Step

There are massive opportunities to advance your security practice as your business moves into the cloud. This talk provides a step-by-step approach that will help you maximize them.

This talk was presented at TASK on 24-Nov-2021.

Abstract

While the rest of the business has jumped into the push towards cloud, how should your security practice adjust? Architectures, visibility requirements, and data protection needs, among others, are different in the cloud.

It can be hard to know where to focus. How can you identify and manage different risks and exposures? There are so many changes, what steps should you take?

In this session, we’ll look at different areas of your security practice, how they shift, and how to prioritize them as your organization moves to the cloud.

The goal is to provide a map of your next steps and to highlight what resources can help you not just move your practice to the cloud but improve it at the same time.

References

Each of the cloud service providers (CSPs) has a Cloud Adoption Framework. These aim to align business goals with technology adoption
They also each have a Well-Architected Framework. These frameworks help your understand the principles and practices required to build well in the cloud
Migrating Securely to Public Cloud: A CISO Cookbook, is a collaboration between Monica Verma and myself. It aims to highlight the primary concerns for CISOs as their businesses move to the cloud
- If you haven’t already, I recommend subscribing to Monica’s podcast, We Talk Cyber
The Unicorn Project Through a Security Lens, is a talk I gave that looks at how security teams can adopt DevOps practices to improve their daily work…while getting along better with the rest of the business
How To Build Strong Security Guardrails in the AWS Cloud With Minimal Effort, uses AWS as an example but is broadly applicable. This talk shows you how the concept of “guardrails” can handle the situations where a simple yes/no answer doesn’t cover it
Death to CIA! Long live DIE! How the DIE Triad Helps Us Achieve Resiliency. A talk given at RSA Conference 2021 by Sounil Yu, CISO & Head of Research at JupiterOne
Audit and compliance presents some specific challenges in the cloud. AWS has an excellent set of resources to help as part of the AWS Audit Manager program

Slides

Slide from presentation, described in the next grid item

We're beyond this now, right?

Let's talk about how we should be working in the cloud.

We—the security community—haven't advanced our work methodology as much as we should because it's a pain in the you-know-what on-premises.

On prem, there are just too many different ways of interfacing with systems. This drives up the cost of automation.

In the cloud, this is simplified greatly. The CSP provides a unified interface through which you can interact with almost all of your stack. That opens up a lot of new possibilities.

Let's take a look at the...

...opportunities
...challenges
...risks

...and come up with a plan.

The Shared Responsibility Model

This model dictates how all operational and security activities work. It shows whether you—the builder—or the Cloud Service Provider (CSP) is responsible for a specific area of the system.

We start with on-premises, where you are responsible for everything. This is the traditional working model but it still lines up with this concept. You were sharing responsibilities. Just with different teams, not external partners.

Moving into the cloud, you immediate delegate 1/2 of the work to the CSP. That only increases as you move towards SaaS-type services.

No matter what, you are responsible for your data and configuring the CSPs service. Those are always your responsibilities.

The business advantages are clear. The more your delegate to your CSP, the more you can focus on providing direct business value.

This means that you should bias towards SaaS-type or managed services whenever possible.

The good news? Security responsibilities follow suit.

People often remark that it's hard to figure out where your responsibilities lie. It turns out, it's actually pretty simple.

You need to verify if you're expected to manage the operating system and the application layers. That's it.

This provides clear areas of security focus...

Your data (access, risk tolerance)
Service configuration (features, settings)
Operating system (harden, maintain, monitor)
Applications (harden, maintain, monitor)
Boundaries (input sanitization, observe)
Identity (who, when, where)

You are already familiar with securing your data, operating systems, and applications. Nothing changes at these layers in the cloud.

So, for this talk, we'll focus on the other areas...

Guiding Tenets

Remember the principles of security don't change...but the way we work needs to.

There are four main tenets...

Feedback loops
Being part of a larger team
Everything-as-Code
Automation

A feedback loop is simply following these steps;

Idea
Experiement
Analyze
Improve
Iterate

Being part of a larger team is hard.

Security teams are typically firefighting constantly. That makes it very difficult to coordinate and collaborate with the rest of the business.

Add to that the chronic challenge of finding enough resources and it's completely understandable why security teams operate the way they do.

But change need to start somewhere. This is a big one and a perfect example of the cliche, short term pain for long term gain.

"as-Code" is a popular buzzword. Thankfully, there's real value behind the hype.

Everything should be code in the cloud. From infrastructure definitions, to security controls, to automations, to...um...code.

Having source or a template or a script that can (re)create whatever is needed is an amazing ability.

It also means we can track changes over time, analyze before running, and programmatically interact with everything in our environment.

DevOps is successful because of their constant put for automation. Security needs to be the same.

Automation is more reliable, faster, and helps take the pressure off of your team.

Service Configuration

Opportunities;

Offload work & responsibility to CSP
Added functionality with minimal effort

This new feature from AWS was just released and it lets you remove a Windows Server remote access tool from your stack.

Instead of exposing RDP access in your design. This feature automatically manages the access securely for you.

Challenges;

Keeping up with CSP release cadence
Builder service adoption

This same AWS remote access featureonly received a couple of paragraphs in the "What's New" stream and a documentation update.

...and this is just one of hundreds of features that get released every year.

Leading up to AWS re:Invent 2021, AWS has already release 215 new features.

Misconfiguration of CSP services is the #1 security issue in the cloud right now.

All of the cloud-specific breaches in the past few years have been a result of misconfigurations.

In fact, the few security issues reported by the CSPs themselves have also been misconfigurations!

Plan;

Regularly follow CSP releases
Strong communications with builders
Monitor usage & configurations

Boundaries

Opportunities;

Simplify application of controls
Minimize operational overhead

Google Cloud Armor is a good example of a boundary control.

It provides DDoS, WAF, and IP access control capabilities for any workload behind it. Whether that's virtual machines, containers, functions or something else.

Challenges;

May not have access to the boundary
Transition coverage may not be 100%
Monitoring & options may not fit risk tolerance

...back to Google Cloud Armor. This service can protect Cloud Functions but if a user or actor knows the direct URL for the function, the request won't pass through Google Cloud Armor.

While still incredibly useful, this control doesn't completely cover the service boundary.