When the concept of zero trust was first introduced in 2010 by Forrester Research, it seemed directly aimed at enterprise security professionals, who were struggling to keep the network perimeter safe from breaches and attacks. As enterprises and zero trust frameworks have evolved, DevOps has become the perfect home for these principles.
Zero trust requires all users – human and machine, internal or external – to be authenticated, authorized, and continuously validated to first access and continue to access resources. These requirements are fully aligned with modern application development and the advent of DevSecOps, where security continues to shift left in the development life cycle.
In 2019, GitLab Staff Security Engineer Mark Loveless began to examine the opportunities in marrying DevOps and zero trust. Much has changed since then, including a greater acceptance, adoption, and, in some cases, requirement of zero trust frameworks. For instance, in its executive order on cybersecurity, the Biden administration referenced zero trust and the National Institute of Standards and Technology (NIST) called out zero trust architecture as an approach to its Secure Software Development Framework standard.
Addressing zero trust confusion
As zero trust strategies have become more popular, confusion in the market has increased. For instance, zero trust is not a single product or service – it is a strategy applied to a security framework.
“Companies are marketing their zero trust solutions as THE solution. They claim that zero trust solves everything wrong and you’ll be secure. No single solution out there addresses all of the authentication problems that organizations encounter,” Loveless says.
Another point of confusion, according to Loveless, is the fact that some early zero-trust backers have not evolved with zero trust itself. “The core beginnings of zero trust go back a couple of decades, originally centered around users and specific systems. There is an entire world of newer technology, including the cloud, automation, and AI, that has emerged since then that is out there and completely underrepresented in approaches to zero trust,” he says.
How zero trust fits into modern DevOps
Zero trust has three core components that must be fully understood to be able to map it to modern application development:
-
Data must be protected. Before the data can be accessed, the identity of who or what (in the case of automation) is accessing the data needs to be determined and a decision has to be made as to whether that access will be granted.
-
The identity must be extremely specific. The requestor must be proven, preferably by cryptographic means, to be who or what they say they are.
-
A secure channel for accessing the data must be able to be established. After authentication, data in transit should be protected by a secure channel and that data should only be revealed to the requestor.
Where zero trust strategies often go astray is assuming that the requestor is human. As automation becomes more prevalent in DevOps, DevSecOps must account for the likelihood that a requestor could be automated. But this inevitably raises questions, according to Loveless, such as:
- Is the automated request coming from a trusted device?
- Who initiated the action that led to the automated process requesting the data?
- Was it an automated process that kicked off a secondary automated process that is now requesting the data?
- Does the person that set up the automated processes still have access to these processes’ credentials?
Loveless says organizations might need to rethink their authentication and authorization approaches to get the most out of the DevOps-zero trust pairing because automation requires a greater level of sophistication. “Mutual authentication strategies like managing your own certificate authority or setting up mutual TLS can be challenging,” Loveless says. Instead, organizations might consider implementing automated multifactor authentication tools such as OpenID Connect. “One solution might negate another solution, or solving for one cloud provider might exclude another, creating limits,” he says.
How GitLab’s DevOps Platform supports zero trust
GitLab’s cohesion with zero trust stems largely from its belief that it is not a single solution to zero trust, but instead part of an ecosystem in support of zero trust principles.
Organizations can utilize GitLab to enact its zero trust framework, including the ability to:
- set and enforce granular role-based access for all users and machines
- authenticate users and machines before allowing access
- require continuous authentication and authorization
- monitor the security status of users and machines and quickly respond to issues
- classify data and set and enforce access levels accordingly
- audit data access in real-time and generate compliance reports
Going forward
GitLab’s commitment to zero trust is foundational and ongoing. As zero trust frameworks evolve and more standards bodies require adherence to zero trust principles, GitLab will continue to be a trusted partner in meeting these demands.
Cover image by Max Tcvetkov on Unsplash
