Kathy Wang, GitLab’s Sr. Director of Security, and Philippe Lafoucrière, a distinguished GitLab Engineer, recently presented “Towards Zero Trust at GitLab.com” at Google’s Cloud Next ‘19 event.
While a simple “zero trust” google search will return a variety of educational resources on the topic, what I valued most about the GitLab teams story was how pragmatically they break down the steps they took (and are still taking) along their Zero Trust journey. It’s also one of the only case studies showcasing a 100% cloud native application protection (CNAPP) organization working to implement the zero trust approach BEFORE a major security breach. Below, I’ll recap the core concepts of Kathy & Philippe’s talk, but you can also catch the full conversation in this YouTube video.
First, let's start with a quick explanation of what Zero Trust is. (or as Google calls it, BeyondCorp.)
Cloudflare defines Zero Trust as:
“...an IT security model that requires strict identity verification for every person and device trying to access resources on a private network, regardless of whether they are sitting within or outside of the network perimeter.”
Kathy shares some additional perspective, saying, traditional network security is heavily perimeter based. Hard on the outside, soft on the inside. When an attacker does inevitably gain access, they can move laterally, gain privileged access, and cause a lot of headaches. Not ideal.
Zero Trust means the device is authenticated and authorized, the user is authenticated and authorized and decisions are risk-based and dynamic; meaning rules are enforced, ensuring that each access request takes into account the context, device used, application and data requested as well as the employee’s role in the organization.
For example, HR data might be available to HR, but only when using a corporate, managed system would an HR employee be able to access salary information. The same goes for system accounts accessing APIs and databases.
In fact, even with corporate backing, Kathy shared that the road to building a Zero Trust Network can easily take 9-12 months. Older companies with a large IT footprint may take much longer, though any incremental progress also reduces risk accordingly and is worth it on its own. Considering this investment in time and resources, it’s helpful to understand why GitLab (and others) see value in building a Zero Trust Network. Kathy cited GitLab’s reasons as:
For another in depth perspective on what Zero Trust is, check out this comprehensive review of a Zero Trust Security Model provided by Akamai Technologies.
This is where the pragmatic and approachable perspective comes into play. Kathy shares that, while the timeline and process for building a Zero Trust Network is long, it can also be broken up into buckets representing independent streams of work that can be built in parallel. Taking this bucketed approach to the build out allows speed and flexibility. We’ll get to GitLab’s defined buckets in a moment, but first, take a look at the foundational policies and systems that were put in place to support their Zero Trust build out:
With that context and foundation, Kathy and team then identified their three main buckets to help “wrap their heads around where to get started.” At GitLab, those buckets became:
The buckets were then expanded into a roadmap to identify the critical components of each work path as shown in the diagram below.
Click here to skip ahead to this part of the video.
Attacking the work across these three segments also required solving three major problems which are outlined below, sharing the process, policy and technologies required:
CSO.com defines Identity and access management (IAM) as “defining and managing the roles and access privileges of individual network users and the circumstances in which users are granted (or denied) those privileges... The core objective of IAM systems is one digital identity per individual.” For GitLab, building an IAM system that worked to provide visibility into their macOS user endpoints and production Linux servers, along with the ability to handle a fast pace onboarding and offboarding of staff was critical. (Kathy shares that GitLab is on track to grow from ~200 to 1,000 employees over a two year period!) GitLab’s IAM system is required to:
Philippe helped to build a system that educated and empowered their developers to own the security of their applications and code, acknowledging that a secure network doesn’t mean much if they’re shipping insecure applications. His goal was to relieve the security team of the burden by “shifting security left” and making it a seamless part of the developers process. Much of what they’ve built below is also a part of their product vision and offering in GitLab Defend.
Here’s the process and tools their engineers and developers use to “Trust What’s Running In Production Environments”:
For a refresher, here’s a helpful article describing the differences between SAST, DAST and IAST.
GitLab.com has over 2 million users that trust their sensitive data to GitLab. It’s not only a customer environment, but where GitLab itself manages their product repos. Ensuring the GitLab.com infrastructure is imperative. Using Google’s security best practices (and the Google Cloud Security Command Center) as a guidepost, here’s what their current process entails:
It’s easy to appreciate how much work has gone into GitLab’s Zero Trust journey and the diligence that was required to plan, evaluate, implement and refine the various components. While Kathy and Philippe have outlined several granular actions/requirements, don’t lose sight of these higher-level takeaways when considering your own Zero Trust Network journey:
Check out the last few minutes of Kathy and Philippe’s presentation to hear about their lessons learned and advice for others considering a Zero Trust Network.
Learn more about Osquery: