How to Manage Risk During Public Cloud Migration

TL;DR

Public cloud risk is managed by recognizing that provider certifications cover only the infrastructure and services the provider owns, while customers remain responsible for their applications, data, users, configurations, and exposure. Build visibility through selective, actionable, centralized logging, then reinforce accountability with automation, defined alert thresholds, accessible security support, and constructive feedback when users make mistakes.

Transcript

Hello, and welcome to this installment of our RSAC 365 webcast series. I'm your host, Casey Zirkus with the RSA Conference team. This month we're focusing on all things that matter to CISOs, and today's speaker, Jabez Abraham, will be talking about risk management for migration into a public cloud provider. There will be time for questions at the e... Read More

Key Insights

• Public cloud security is a shared responsibility because the provider protects and certifies what it owns, while the customer remains accountable for applications, data, users, configurations, and access built on top of the provider's infrastructure.
• Provider compliance does not automatically make customer workloads compliant because certifications such as FedRAMP or CIS apply to the relevant provider-controlled platform components, not necessarily to how customers build, expose, and use their own systems and data.
• Visibility is a pivotal cloud risk-management capability because security teams need enough information to identify inappropriate access, investigate failures, recognize unexpected communication paths, and decide which events require corrective action.
• Effective logging is selective and actionable because recording everything can create so much data that troubleshooting becomes impractical. Organizations should prioritize events they can investigate or respond to, including failures, denials, rejections, and relevant network activity.
• Successful connections can reveal security problems because a development user or server may reach production through access that was mistakenly granted. Monitoring only denied traffic would miss this misconfiguration and the unauthorized communication it permits.
• Centralized logging is a recommended pattern because logs can be isolated in their own contained environment, helping preserve visibility and investigative information when threats such as ransomware affect other parts of the organization's environment.
• Constructive user feedback improves cloud security because developers, sales personnel, and other users may make genuine mistakes or misunderstand controls when working with a provider. Accessible security teams can correct exposure while building confidence and cooperation.
• Accountability depends on defining normal activity because security professionals need a manageable alert threshold, automation for volumes beyond human capacity, and clear communication paths such as remote messaging channels or a shared security email list.

Questions & Answers

Q: What is the shared responsibility model in public cloud security?

The shared responsibility model separates what the public cloud provider controls from what the customer builds and manages. The provider is responsible for its core infrastructure and the compliance claims associated with provider-owned components. The customer remains responsible for its data, applications, users, access permissions, configurations, and exposure. Therefore, using a certified provider does not automatically make every customer workload compliant or secure.

Q: Why do cloud provider certifications not guarantee customer compliance?

Cloud provider certifications apply to the systems, infrastructure, and services covered by the provider's compliance program. Customer-created applications, stored data, user access, network exposure, and configurations sit on top of that foundation and remain the customer's responsibility. An organization can benefit from a provider's FedRAMP, CIS, or other certifications, but it must still demonstrate that its own implementation satisfies applicable compliance and regulatory requirements.

Q: What should an organization log during a public cloud migration?

An organization should prioritize events that security personnel can investigate and act upon. Examples from the presentation include failed activity, access denials, rejected connections, and relevant networking records such as VPC flow logs. Logging should also capture successful communication that violates intended boundaries, such as traffic originating in a development environment and reaching production. The goal is useful visibility, not indiscriminate collection.

Q: Why can logging everything make cloud security less effective?

Logging every possible event can create an overwhelming volume of information and make practical troubleshooting difficult. The presentation recommends identifying specific events that support a response or investigation. Security teams can focus on failures, denials, rejections, suspicious network paths, and successful access that should not occur. This approach connects visibility to action and helps teams avoid accumulating records they cannot meaningfully review.

Q: How can security teams detect improper development access to production?

Security teams can monitor traffic between non-production and production environments, including successful connections rather than only blocked attempts. A developer or development server might reach production because access was configured incorrectly. If monitoring covers only denials, that successful but inappropriate path may remain invisible. Recording who communicates with production, and from which environment, allows the team to identify and correct unintended permissions.

Q: Why should cloud logs be centralized and isolated?

Centralized logging brings relevant records into a contained environment where security teams can investigate activity across cloud resources. The presentation also recommends isolating logs from the systems they describe, particularly in light of ransomware and similar threats. This pattern can protect investigative visibility when another environment is affected. Centralization still requires deliberate selection of useful events so the collected information remains actionable.

Q: How should security teams respond when cloud users make mistakes?

Security teams should correct unsafe conditions while creating a positive feedback loop with the user. Developers or other personnel may make genuine mistakes, misunderstand controls, or accidentally expose a resource to the internet. Rather than belittling them, security professionals should be accessible, explain the issue, and build a relationship that encourages users to seek help. That cooperation supports safer behavior throughout the cloud journey.

Q: How can a security team improve accountability for cloud alerts?

A security team should first determine what normal activity looks like and establish an alert volume it can manage each day. When activity exceeds that threshold, the team should consider automation or other handling methods. Accountability also requires clear ways for users to reach security, especially in remote work settings. Examples include a messaging channel and a common email list that reaches several responsible people.

Summary & Key Takeaways

• Public cloud migration uses a shared responsibility model. A provider may hold FedRAMP, CIS, or other certifications and offer infrastructure availability commitments, but those assurances do not automatically make customer workloads compliant. Organizations remain responsible for the applications, data, users, access decisions, configurations, and exposure they create on top of the provider's platform.

• Visibility should be designed around information that enables action, rather than collecting every possible event without a practical way to investigate it. Useful examples include access failures, denials, rejected connections, network flow records, and successful traffic from development systems into production. Centralized, isolated logging can also help protect evidence during incidents such as ransomware.

• Accountability requires security teams to understand normal activity, establish a manageable alert threshold, and automate responses or handling when alert volume becomes excessive. Users also need accessible ways to contact security, including shared email lists or remote communication channels. Constructive feedback helps developers and other users report mistakes and improve their cloud behavior.