Security Cloud Courses About
imgs/hero.webp

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

Slides

Click on the slides for larger versions

Slide from presentation, described in the next grid item

We're beyond this now, right?

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

Let's take a look at the...

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

...and come up with a plan.

Slide from presentation, described in the next grid item

The Shared Responsibility Model

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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)
Slide from presentation, described in the next grid item

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...

Slide from presentation, described in the next grid item

Guiding Tenets

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

There are four main tenets...

  • Feedback loops
  • Being part of a larger team
  • Everything-as-Code
  • Automation
Slide from presentation, described in the next grid item

A feedback loop is simply following these steps;

  1. Idea
  2. Experiement
  3. Analyze
  4. Improve
  5. Iterate
Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

"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.

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

Service Configuration

Slide from presentation, described in the next grid item

Opportunities;

  • Offload work & responsibility to CSP
  • Added functionality with minimal effort
Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

Challenges;

  • Keeping up with CSP release cadence
  • Builder service adoption
Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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!

Slide from presentation, described in the next grid item

Plan;

  • Regularly follow CSP releases
  • Strong communications with builders
  • Monitor usage & configurations
Slide from presentation, described in the next grid item

Boundaries

Slide from presentation, described in the next grid item

Opportunities;

  • Simplify application of controls
  • Minimize operational overhead
Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

Challenges;

  • May not have access to the boundary
  • Transition coverage may not be 100%
  • Monitoring & options may not fit risk tolerance
Slide from presentation, described in the next grid item

...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.

Slide from presentation, described in the next grid item

Risk;

  • Misconfiguration in the CSP offering
  • Lack of flexibility in control
  • Only options could be insufficient
Slide from presentation, described in the next grid item

Plan;

  • Test, test, test
  • ...continue to test
  • Mitigate gaps with defence in depth
Slide from presentation, described in the next grid item

Identity

Slide from presentation, described in the next grid item

Opportunities;

  • Full traceability within your systems
  • Actual least privilege environment
  • Reduce operational overhead
Slide from presentation, described in the next grid item

Challenges;

  • AWS links identity to account
  • Legacy structure don't align to tasks
  • Sheer scale of the problem
Slide from presentation, described in the next grid item

Risk;

  • Users have incorrect permissions
  • Systems have incorrect permissions
  • Things don't work
Slide from presentation, described in the next grid item

Plan;

  • Use federated identity system
  • Align groups/roles with tasks
  • Monitor and assess regularly
Slide from presentation, described in the next grid item

Step-by-step

Slide from presentation, described in the next grid item

Step 1;

  • Read Cloud Adoption Framework
  • Read Well-Architected Framework
  • Align with overall business cloud strategy
Slide from presentation, described in the next grid item

Step 2;

  • Start with a simple feedback loop
  • Iterate...a lot
  • Map out other feedback loops in your practice
Slide from presentation, described in the next grid item

Step 3;

  • Make sure all controls are in a template
  • Test, test, test some more
  • Verify that all CSP services, applications, and deployments are observable
Slide from presentation, described in the next grid item

Step 4;

  • Start & contribute to security code repo
  • Automate a simple task
  • Rinse & repeat...everything should be automated
Slide from presentation, described in the next grid item

Step 5;

  • Work in the open
  • Collaborate constantly
  • Teach other the WHY behind security decisions
Slide from presentation, described in the next grid item

Step 6;

  • Create a culture of constant learning
  • Question & test everything
  • Share the security work with other teams
Slide from presentation, described in the next grid item

Thank you!