How (Not)? To Move A Security Practice To The Cloud

Most security practices make the same set of mistakes when moving to the cloud. This talk looks at those mistakes and how to avoid them.

This talk was presented at SPIE on 25-Nov-2021.

Abstract

When a business moves to the cloud, there are six major strategies they use for each IT service. Whether they move a system “as-is” or do a complete re-architecture, each approach has specific advantages and disadvantages.

When a security practice moves to the cloud, it’s almost always using the same “as-is” strategy. Why?

In this talk, we’ll examine that predominant strategy and explore its impact. We’ll also take a look at what we could—and should—be doing in cloud environments to move our cloud security practices forward.

Can security get the same benefits from the cloud as the rest of the business? Let’s discuss the challenge together!

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
Updating Your Security Practice for the Cloud, Step-by-Step
An example of what automation can bring to your security practice can be found in the AWS Well-Architected Labs

Slides

Slide from presentation, described in the next grid item

Business use any combination of these six strategies to migrate to the cloud.

Retire
Retain / revisit
Repurchase
Re-platform
Re-host
Refactor / re-architect

...but security typically only uses one, "Retain / revist"

Why?

Security really should be focusing on improving their practice by leveraging the three options that lead to a cloud native practice; re-platform, re-host, refactor/re-architect.

Remember, throughout this process the principles of security don't change. But we do need to change the way we—the security community—work.

Your Current Reality

Let's accept for a minute our current reality in the security community.

We're constantly fighting fires. There's no time to work on anything forward looking.

Even if we did have the time, we're not involved in the rest of the business at the levels we should be.

...and we simply don't have the resources to do the job we're tasked with.

😔

How (Not)? To Move

Stop saying no. Stop moving slow. Stop adding weighty processed to everything.

It should be obvious, but don't fork lift you're current practice into the cloud.

That way madness lies...

Instead, we need to focus on the Shared Responsibility Model, automating everything, and delegating security responsibilities to other teams who are better positioned to meet our goals.

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 means your areas of security focus should be...

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)

Identity

We make a lot of assumptions on-premises about our security practice. In fairness, they're usually true.

Permissions align with teams
Systems are long lived
IP addresses used as identifiers
Environment is predictable

...these don't hold up anymore.

Permissions change significantly in the cloud. Some key areas;

IAM fabric is built in to each cloud
Easy to verify which permissions used
Permissions should align to tasks
Manage at the group/role level

The lifecycle of systems in the cloud is unrecognizable compared to on-premises. You should be looking in to...

Capacity management no longer being an issue
Resource becoming ephemeral
Fixing/remediating issues in templates and then re-rolling production

The IP is the gold standard for system identity on-premises. That's out the window in the cloud.

IPs are re-assignable
IPs might not be controllable
CSP assigns immutable identifier for each resource...use that!

If you haven't figured it out yet, the overall environment in the cloud is drastically different from on-premises...and that's a good thing.

Teams are constantly experimenting
Resources have wildly different lifecycles
CSPs constantly roll out new features

Speed

Again, we deal with a set of assumptions from our on-premises environments.

Strong, manual change management
Systems are long lived
Slow rate of change

Gone are the days of manual change process. Automation is key to success here.

Automated system, ideally CI/CD
Significant increase in volume of changes
Can validate the environment programmatically

Resource lifecycle is very dynamic in the cloud. The effort to get something in production is so low, that it happens all of the time.

Capacity management no longer an issue
Most resources are ephemeral
Fix/remediate in template, re-roll production

We've touched on this a few times already, the rate of change is exponentially faster than on-premises.

One API call can build almost anything
Feedback loops in DevOps philosophy
Push for digital transformation

Collaboration

The assumptions built up on-premises have helped security operate. Again, these were made through a series of logical steps but the result doesn't make sense in today's reality.

Security as a gating function
Common infrastructure
Accepting of "cost" of dealing with security

Gating is a useful tool for security teams. It doesn't go away in the cloud but it does change significant. Gates should now be full automated and transparent to other teams involved with the systems.

Automated, not manual, verification
Guardrails used in "maybe" situations
Approval tied to automated risk evaluation

As with everything else, the infrastructure is very different in the cloud.

Environments are separated at the CSP level
Workloads are logically isolated by the CSP
Common standards and configurations set structure for the organization

No security team wants to work in isolation. However, the lack of time, constant firefighting, and other constants make it really hard to work together effectively.