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.