Update: This is part 2 of an ongoing Zero Trust series. See our next post: Zero Trust at GitLab: The data classification and infrastructure challenge.
Zero Trust is the practice of shifting access control from the perimeter of the organization to the individuals, the assets and the endpoints. For GitLab, Zero Trust means that all devices trying to access an endpoint or asset within our GitLab environment will need to authenticate and be authorized. This is part two of a multi-part series. Read the first post, The evolution of Zero Trust.
The benefits of Zero Trust Networking (ZTN) on paper are ideal and many rush to implement it with no idea exactly what it is (or how to get there). We previously discussed the evolution of ZTN and have been working on ways to implement things since then.
Vendors have appeared left and right, trying to sell their own versions of ZTN, but curiously no two seem to have the same interpretation. All of them say they have a product that does ZTN and it is “easy to use,” but of course if you nail them down on the implementation they all seem to fall short in one area or another.
Defining the problem
I alluded to this above, but let’s clearly restate the problem – how does a diverse company implement Zero Trust when no one can seem to agree on any of it? The most common issue for those trying to roll out a ZTN is that, to be successful, everything must work together. The basic principles of Zero Trust – positively identify the user, positively identify the device accessed as managed and secure, ensure the user and the device are allowed to get into the asset they are trying to access, and do all of this in real time – are somehow very hard for most people to understand.
We probably should have clearly stated in our last blog post that the biggest problem with the BeyondCorp solution outlined by Google is that it is tailored for Google. This series of blog posts will take a closer look at the issues we are trying to solve, along with our working approach. It is tailored for GitLab and won’t necessarily work everywhere else. Hopefully it will provide insight into our thought process, encourage some discussion, and possibly help others along their own paths.
What we want
Implementing ZTN at GitLab involves determining what we want out of this, which is really an extension of our objectives for GitLab security in general. What we want to do is the following:
- Protect the data that needs to be protected. Different types of data need to be protected at different levels, so we must be able to have that flexibility.
- Positive team member identification. When a team member authenticates, we need to know it truly is that team member, and we need to know what the allowable data is. This needs to happen in real time.
- Positive device identification. We need to identify the authenticated team member’s access device, and based upon the level of trust associated with that device, determine whether the device is allowed to access particular data, regardless of team member identity. This needs to happen in real time.
- Geo-location identification. We need to identify the team member’s location while at work and restrict access to certain data based upon team member geolocation. This needs to happen in real time.
- Automated access. We need to subject all automated processes that access data to the same data protection policies as team members and devices. Again, this needs to happen in real time.
- Logging. We need to properly log all transactions for auditing and monitoring purposes.
- No weakening of existing controls. Data must be protected at rest and in transit. Any and all solutions should not detract from this.
- Security should make things easier, not harder. If we do this correctly, the process will be streamlined. Team members in general should be able to do their jobs effectively and quickly. Security should be so streamlined that the process is not cumbersome, as this tends to inspire some team members to try and bypass it.
Expected challenge areas
We’ve laid out what we want to do, and it was pleasant to discover in quite a few cases we are already doing just that. We just lacked either the real-time component or we simply had some type of inconvenient workaround to protect data that inhibited team members from doing their jobs easily. Based upon that knowledge and what we want to achieve, we’ve devised a list of potentially challenging areas we may encounter:
Our network
We are a company that has no perimeter to speak of, as all team members are remote. In a way this is good, since we don’t have a corporate VPN and therefore don't have to face dismantling it. But we do have to ensure that we maintain some semblance of control so we are assured that as a team member authenticates, it is done in a safe way and is independent of the network they are using.
Our apps and our data
We use a number of products, including our own DevOps offering. While we can control our own product and alter it to better serve our needs (and subsequently release said changes to our customers for their own needs), this does not address the public cloud offerings our infrastructure is based on and that we use on a regular basis: GCP, AWS, Azure, and Digital Ocean. Nor does it consider the variety of controls (and their variations) used to administer and secure these platforms. Solutions that present themselves as working just fine on one cloud offering may not work the same (or at all) on another platform, which causes its own challenges. It also does not address additional services such as Slack, Expensify, BambooHR, Zendesk, and others that contain data we have to protect. Therefore, we need to extend our protection to cover our data no matter where it resides.
It’s not just us
We sell services to customers including private groups and projects on GitLab.com that need protecting from the public and whose access is restricted from us on a need-to-know basis.
Scaling
We’re growing at a rather accelerated rate, in terms of both customers and team members. All solutions to problems have to scale, including security solutions such as ZTN.
Our customers are global
There are contractual obligations, and as well as regulatory and compliance issues, across the globe for our customers that need to be observed.
Our team members are also global
There are unique issues across our diverse team member base, residing in more than a quarter of all countries on the planet. Each country has its own regulations, standards, and needs.
Coming next
We think some of these challenge areas might look familiar to many of you, and while we hope this post has been useful we're definitely heading into some deep and murky water going forward! In the next post, we’ll take a dive into the deep end of this far-from-straightforward issue in to one of the more challenging areas: our data and the infrastructure it resides upon.
Special shout-out to the entire security team for their input on this entire blog series.
