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

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.

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

Next Steps

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.

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.

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!

Thank you!