Six Essentials for Your Cloud Security Program

In traditional on-premises systems, organizations are responsible for securing everything – from the physical premises to the hardware, operating system, network, and applications.

In cloud deployments, it doesn’t work that way. In public cloud – both infrastructure as a service and platform as a service – security responsibility is shared between the CSP and the customer (you). The provider owns the security of the physical layer and infrastructure aspects of the cloud as well as the aspects of the compute, storage, database, and network and application services they offer. You, the customer, own the security configuration of your own operating systems, network traffic, and firewall settings – plus all security on your own systems that are used to connect to the cloud. To be secure, it’s imperative that you understand the security you own.

With a broad understanding of the Shared Responsibility Model, let’s review six cloud security essentials that must ALWAYS be addressed.

Classify apps and data

Ask yourself which applications and data you have that are critical to running your business. Start your security efforts here. Which apps and data would cause executive leadership, stockholders, or customers to abandon ship if breached? What data, if leaked, could cripple the ability to conduct business or effectively compete? What data would cause regulators to get into a whirr and possibly result in fines or sanctions? Highly coveted business data and government-regulated data must be classified as critical and protected.

Keep an eye on application security

Attackers often target vulnerabilities in your web applications. To ensure your applications are free from software vulnerabilities, you should actively look for vulnerabilities that create security risks. If the applications are open source or off-the-shelf, make sure to patch regularly and be sure to patch critical security flaws immediately. When building your applications, ensure your developers are trained to use secure coding practices and continuously examine the apps for potential flaws. A good place to look for guidance on how to start an application security program is the Open Web Application Security Project (OWASP).

Get user identities and access under control

Put processes in place to manage your user identities. This entails knowing who your users are, what job roles they have, and which applications and resources they should be able to access. It’s important to limit access to only those who have a reasonable need for those resources. When the roles of these people change, change their access. When someone leaves the company, for whatever reason, have their access revoked. This is one of the most important things you can do to keep a good security posture, yet it’s one of the areas that is so often overlooked.

Establish and manage policy and configuration

It’s crucial to establish policies for security checks, settings, and configuration levels for all systems, workloads, and apps. As with vulnerability scans, first and foremost, it’s important to find systems that are out of date, and then check to ensure systems are configured and running in accordance with policy.

If it can be automated, automate it

If there is a security task that can be automated through scripts or cost-effectively offloaded to a security services provider, it should be done. This e-book offers some helpful tips. If you are a smaller organization, scale the advice down to your size, but the precepts remain similar.

Be ready to respond

Of course, being on a steady lookout for security deficiencies in your organization is important, but many organizations, unfortunately, don’t bother to think about what comes next: remediation. When you start looking for security vulnerabilities, what will the organization do to remediate them? When you find violations of policy compliance, how will you quickly close the gap? Be sure to think these through and plan ahead.

Applying Zero Trust to Google Cloud Environments

At Palo Alto Networks, we’ve been helping our customers make a dramatic, transformative shift on how they approach security. This journey is not just about the implementation of technologies, but rather a change in the very philosophy on what security is and how it should be designed across the enterprise.

In the past, the traditional perimeter model for security was based on fortifying the demarcation between trusted and untrusted areas of your network. The convention presumed that your users and applications were in the trusted parts, and the internet and threats were in the untrusted parts. This model is fundamentally broken today. Mobile workforces and cloud applications are not inside the trusted part of the network. The model is also broken because it cannot stop a threat actor that is operating within the trusted network. Furthermore, even with the separation between network boundaries in place, conventional port and protocol security lacks the granularity to enable applications and stop attacks from passing back and forth anyway.

The right philosophy should challenge the notion of trust in the first place, and implement the necessary controls to enforce least-privileged access – in other words, Zero Trust. For example, never presume something to be trustworthy. Build enabling policies based on the context of the user and application, rather than trying to block everything you don’t want. Don’t presume a file is safe just because it’s not known to be bad. With Zero Trust, we drive policy to enable what is allowed, rather than try to identify every possible permutation of what isn’t.

Toward this end, we have developed a tremendous number of important technologies to establish complete visibility, reduce the attack surface, prevent known attacks, and detect and prevent unknown attacks. Four real-time capabilities at the core of the Palo Alto Networks Security Operating Platform are App-ID, which classifies and identifies applications and functions; User-ID, which automatically assigns identity to otherwise anonymous network flows; Host Protection, which provides device posture and exploit and malware prevention; and Content-ID, which performs inspection of content, in order to detect and prevent malicious actions. All of this rich context is made available to be leveraged in our customers’ security policy and decision-making process.

As part of our customers’ journey to the cloud, we believe that the same Zero Trust philosophy toward security is mandatory, whether that means building their own applications in the cloud with IaaS and PaaS services or consuming pre-built cloud applications through SaaS. Google shares many of the same beliefs, as implemented in BeyondCorp, a framework for securing apps and infrastructure based on the principles of Zero Trust.

We are announcing our commitment to work together with Google to develop integration that makes the implementation of secure cloud applications easier. With respect to BeyondCorp, we believe that our mutual customers will benefit from the integration to address implementation challenges with identifying users, maintaining consistent policy, protecting data and enforcing threat prevention across a diverse landscape of users, workloads and devices.

How does this help secure Google Cloud APIs?

The various DevOps teams within your organization are building Google Cloud applications and interacting with a number of Google Cloud APIs. You want to have the granularity to make sure that every team member has access to the APIs that they need, without having to provide unnecessary levels of access to the most sensitive APIs if it isn’t necessary. Contextual information helps drive policy because the level of access that a person needs may be driven by their individual responsibilities, their role in the organization, or even the device that they use. This is the classic least-privilege problem because you can reduce the attack surface area by limiting access based on context, as long as that context information is available.

The intersection of identity (based on user/device characteristics) and the enforcement of access control policy has traditionally been done at the time of authentication. We believe that working together, we can do better than that. If we can limit access so that unauthorized users never get the chance to make an unauthorized API request in the first place, we can cut the attack surface area, mitigate the risk of credential abuse, and reduce the security alerts for failed authentication. This is possible by working together to integrate our identity/device technologies, and we believe it will significantly improve the overall security of the operating environment.

How does this help secure G Suite?

At Palo Alto Networks, we have been relentlessly focused on building protections for applications and data in the cloud. We have taken innovative approaches toward SaaS applications, in particular, being at the forefront of integrating CASB API protections for data security with our platform for inline security. Our customers are using our platform to identify risks, mitigate threats and protect data across the broad landscape of SaaS applications in use in the enterprise today.

Productivity applications such as G Suite are used by nearly everyone within the organization, and as such, they are accessed by an extremely diverse spectrum of employees and contractors, using a mix of devices that may or may not be owned by the organization. By integrating Palo Alto Networks protections for SaaS applications with G Suite, we can build out the user/device context that drives BeyondCorp policy decisions for access. Employees with managed devices get immediate, full access to their applications, while contractors on non-compliant devices receive different levels of access. Again, by working together so that we can exchange context, while also incorporating our threat and data protection, we can help our customers deploy G Suite securely to all employees.

How does this help secure apps on GCP?

The principles of using contextual access and threat prevention together should be consistently applied from the data center to the cloud, without skipping a beat. We know that different app developers and organizations have different ideas about how they approach security, and that consistent, contextual protection is often hard to achieve. By working together with Google, we want to make sure that, as organizations move their applications from the data center to the cloud, the user experience remains the same and consistently safe, regardless of where the user is located. For users on managed devices, only the authorized user with a compliant device can access the application (whether in the data center, cloud or SaaS). For users on unmanaged devices, we enable access to the application without bringing the device on network, thus maintaining a least-privileged architecture without disrupting business.