Security Cloud Courses About
imgs/hero.webp

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

Slides

Click on the slides for larger versions

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

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

Why?

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

Your Current Reality

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

😔

Slide from presentation, described in the next grid item

How (Not)? To Move

Slide from presentation, described in the next grid item

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

Slide from presentation, described in the next grid item

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

That way madness lies...

Slide from presentation, described in the next grid item

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.

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

Identity

Slide from presentation, described in the next grid item

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.

Slide from presentation, described in the next grid item

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

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

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

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

Speed

Slide from presentation, described in the next grid item

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

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

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

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

Collaboration

Slide from presentation, described in the next grid item

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

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

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

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.

  • Digital transformation is accept at the board level
  • Builders moving fast under DevOps philosophy
  • Systems over people and feedback loops drive internal change

👆 all of these things make it clear that if the security community doesn't change, it'll be passed by. No one wants that.

Slide from presentation, described in the next grid item

Next Steps

Slide from presentation, described in the next grid item

Step 1.

  • Understand cloud as an environment
  • Integrate with cloud strategy for the business
  • Read "Cloud Adoption Framework" and "Well-Architected Framework"

This step is all about coming up to speed on what the is and what it means for the business. Take off your security hat and just learn.

Slide from presentation, described in the next grid item

Step 2.

  • Accept "Systems over people"
  • Build feedback loops for security
  • Automate everything

This step gets you "cloud-y". Becoming comfortable with the core drivers of cloud is critical to security success.

Slide from presentation, described in the next grid item

Step 3.

  • Build strong relationships with other teams
  • Teach the why of security decisions
  • Iterate...a lot

With a strong foundation underneath you, it's time to branch out. Working in a modern way with other teams throughout the business.

Remember the key is small steps over and over again. With each one, make sure you are learning and getting a little bit better!

Slide from presentation, described in the next grid item

Thank you!