4 Secure Framework Considerations Before Deploying Workloads in The Public Cloud


By Jhilam Biswas, Customer Engineering Manager, Google Cloud

Enterprises are adopting public cloud providers like never before. Gartner estimated the global forecasted spend on public cloud services to grow by 20% from 2022. Enterprises adopt cloud for several reasons – a couple of them being pay-as-you-go flexible pricing models and scalability.  However, when moving infrastructure to the cloud – be it core compute services, serverless technologies, databases, analytics stack etc., security is often left as an afterthought. The repercussions of that mindset are huge, sometimes leading to significant financial losses, irreversible damages and a negative impact on the enterprise’s brand image. Hence moving to the cloud requires a thorough evaluation of potential risks, compliance obligations and assessment of your business requirements. A recent Gartner report calls out “Through 2025, 99% of cloud security failures will be the customer’s fault.” In this article, we’ll cover 4 secure framework considerations that an enterprise should absolutely be considering before making the move to the cloud.

  1. Review Shared Responsibility Matrix in the Public Cloud

It is important to clearly understand the shared responsibility model when you think about securing workloads in the cloud. The shared responsibility matrix is a consolidated framework that categorizes the security and compliance responsibilities of public cloud providers and customers of the cloud provider. At a high-level, the cloud provider is responsible for the physical security of the core cloud infrastructure, including the data centers, networks, and hardware and the customer is responsible for securing their data and applications, including configuration of access control and data encryption.

What is extremely critical to bear in mind is that nobody knows the security and compliance requirements for your business better than you, and so before you run your workloads in the cloud, you must identify the security guardrails that you need to protect your proprietary data and adhere to regulatory requirements deemed by the industry you operate in. The following diagram shows how responsibilities are shared between the cloud provider and customer.

Image Source:

https://www.cisecurity.org/insights/blog/shared-responsibility-cloud-security-what-you-need-to-know

  1. Identify Risks to Your Organization

Risk assessment is a prudent ongoing process of methodically identifying, evaluating, and mitigating risks to an organization’s assets. It is a process that should be repeated and conducted regularly as your organization’s assets and risks change. Before you move workloads to the cloud, it is imperative to complete a risk assessment to determine what security features you need to meet your internal security requirements and external regulatory requirements. It is important to involve all stakeholders in the risk assessment process, including your cybersecurity teams, IT, and business users. Various risk assessment frameworks such as the Cloud Security Alliance’s Cloud Controls Matrix (CCM) are widely used across industries. After you have identified your risks using such frameworks, you need to determine how to address them. This may involve accepting, avoiding, transferring, or mitigating the risks. You can choose to mitigate risks either using technical controls such as using built-in cloud native features or contractual protections such as ISO or SOC 2/3 certifications that the cloud provider commits to undergo periodically. The results of the risk assessment should be documented thoroughly and should form the basis of your security readiness in the cloud.

  1. Assess Your Compliance Obligations

When you think of your compliance requirements in the cloud, they are dependent on a variety of critical factors such as:

  • The laws and regulations that are tied to your organization’s and your customers’ physical locations (Example: GDPR in the European Union)
  • Your regulatory requirements of the industry that you operate in (Example: HIPAA for healthcare and life sciences)
  • The type of data you store and process in the cloud (Example PII data)
  • The cloud services you use (Example: are the managed cloud offerings that you intend to use for your workloads covered under HIPAA?)

The responses to the above questions dictate which security controls you need to implement for your workloads in the public cloud. A typical compliance journey goes through three stages: assessment, gap remediation, and regular monitoring to check adherence to compliance standards. A comprehensive compliance assessment involves a detailed review of all your mandatory regulatory obligations and how your organization is currently putting it to practice. Once you have a clear understanding of your current state, you can begin to identify any gaps between your requirements and your current practices. The next step of remediating those gaps involves implementing the latest security controls and updating your existing policies that are outdated. The final stage of the compliance journey is continual monitoring. This step is important to ensure your organization is up-to-date with changing regulations. To adhere to compliance even amidst changing regulations, you should consider automating your cloud infrastructure security policies by incorporating them into your infrastructure as code (IaC) deployments. You could also use a cloud compliance management platform to help you track your compliance posture and identify any gaps and last but not the least, stay up-to-date on the latest regulatory changes.

  1. Understand Your Privacy Requirements and Build a Robust Plan to Adhere To Those

Privacy requirements of your organization are dictated by how you acquire, process and store data – both of your internal users and that of your external clients. As the organization grows, building a robust set of security controls to ensure privacy becomes increasingly complex and it might seem like a daunting task to keep up with the changes. However, a methodical and well-thought framework will help you to adhere to the privacy requirements of your organization. Below are several approaches to think about when considering privacy requirements:

  • Define ‘Confidential/Sensitive Data’ as it pertains to your organization: For example, this could be PII information such as SSN, home address, email etc. Classifying this data will help you identify what needs to be protected most carefully. Once identified, consider approaches such as tokenizing, obscuring or de-identifying PII data even to folks within your organization
  • Lock down access to sensitive data: Use identity and access management controls to implement ‘least privilege’ and limit access to sensitive data. Use tools for audit trails to get granular insights on who in the organization accessed what type of data and use that information to further restrict access if the controls are over provisioned.
  • Monitor for phishing attacks: Phishing attacks via email are the most common attack mechanisms for fraud and malware. Ensure you have the necessary protection systems in your email servers to limit the attack servers. SaaS email systems such as Gmail have advanced protection mechanisms against phishing built-in.
  • Extend zero trust security in your organization: The traditional approach to cybersecurity is based on the idea of a perimeter. This means that organizations build a perimeter around their networks and then try to keep unauthorized bad actors out. With the rise of remote work and cloud computing, it is no longer possible to simply keep everyone out of the network and protection simply based on a perimeter model is outdated. Zero trust security takes a novel approach to the “keep the bad actors out” problem. In a layered zero trust model, the concept of perimeter ceases to exist and no one is trusted implicitly. This means that every access request needs to be passed at several levels of checks such as device identity, user identity etc. before the request can make its way all the way to the resource that it has seeked access to. For example, you could use Google Cloud’s out of the box BeyondCorp solution that helps enterprises implement zero-trust at-scale.

 

After you have done the due diligence of doing a thorough analysis of the 4 secure framework considerations as called out above, you can confidently say that you are ready to deploy your workload in the cloud. Depending on what kind of workload you intend to run in the cloud – such as analytics, managed Kubernetes, serverless, databases etc., the next step is to deep-dive into the security features of the specific cloud native services that you are planning on using for your workload. Specifically, the three key areas where you want to focus next are – application/infrastructure security, network security and finally data security (at-rest, in transit and while processing) Last but not the least, consider using a logging and detection tool and a centralized monitoring platform which will help you to quickly view all your threats and vulnerabilities in a single place and take actions on them immediately before you incur a potential attack that can tarnish your organization’s reputation.

About the Author

4 Secure Framework Considerations Before Deploying Workloads in The Public CloudJhilam Biswas is an experienced cybersecurity professional with over 9 years of experience in cloud computing and security. She’s currently a Customer Engineering Manager at Google Cloud helping strategic digital native clients to deploy and scale securely in the cloud. Before Google, she has worn many security hats in different F500 companies such as Security Solutions Architect at Akamai and Security Engineer at Cisco. She earned her MS Degree from the University of Maryland at College Park with a focus on cloud computing and network security. Jhilam can be reached online at https://www.linkedin.com/in/jhilambiswas/ and at our company website  https://cloud.google.com/



Source link