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.
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!
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
An example of what automation can bring to your security practice can be found in the AWS Well-Architected Labs
Click on the slides for larger versions
Business use any combination of these six strategies to migrate to the cloud.
- Retain / revisit
- Refactor / re-architect
...but security typically only uses one, "Retain / revist"
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)
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
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
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.
- 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.
- 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.
- 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!