Business Process Outsourcing (BPO) is when you hire a group of contractors from a single company to complete long-term work for you. This is typically something like customer support, where you want to outsource first-line tech support to a cheaper region or get more coverage in a timezone where you don’t have an existing presence.

The problem is that zero trust architecture requires every employee accessing your critical SaaS applications to come from a managed device. Sending out managed devices to BPOs who might only work just a few days before moving on to another project is downright costly, especially if you’re giving them expensive Macbooks for the task. Add the logistics factor; getting them the laptop for their starting day and the complications around who supports the hardware gives you a situation where you have significant management and cost overheads for an engagement that is supposed to save money.

Additionally the risk is higher when it comes to BPOs. While the value they bring is huge, so is the risk and many large companies have had issues with BPOs being a security issue, whether it’s Instacart, Shopify or Okta which have had issues either via malicious insiders or poor security controls at BPOs.

In this blog, I’m doing a market analysis of some of the potential paved paths in this space, some of the tradeoffs you’ll need to make, and some of the more common vendors for each area.

Use Case Analysis

You can only deploy a solution once you understand the internal use cases, and there are certainly plenty of them. You really want to deep-dive internally and find out how BPOs work in your company.

  • You might have BPOs that provide very basic first-line support, accessing a ticketing system and a couple of SaaS apps.
  • You might have second or third line support which might need to fire up virtual machines and debug instances.
  • At the far end of the spectrum, you might have developer BPOs, building out things like integrations or parts of your product.

These are some of the most common situations I’ve seen, but you can have the whole gamut. In Atlassian, we used to have several different BPO companies, and each would do different things depending on its specialty.

The summary here is:

  • Go and talk to your internal teams that use BPOs
  • Go and talk to the BPO themselves
  • Find out what they do and how they do it
  • Make any changes to the BPO processes first before starting your project to start from a clean slate.
  • Then, finally, build out your requirements for your zero trust solution.

Chain of Trust

For trust to be absolute, you must maintain the chain of trust in the entire flow, from beginning to end. In zero trust device security terms, this means that you need to:

  1. Use a trusted supplier of hardware
  2. Use a trusted logistics chain to deliver those devices
  3. Automatically MDM enroll devices, ideally with ACME certificates, upon first setup
  4. Validate the device and user upon accessing sensitive corporate systems
  5. Keep continuity of the device through it’s lifecycle
  6. Adequately remove data and decommission the device through disposal, recycling, buybacks, or donation.

You cannot bootstrap trust if the chain is broken, which means if you do break this chain, you introduce potential attack vectors into your design. The further down the chain you try to re-establish trust, the more vulnerabilities you’ll have. This is a hugely important factor in the options we pick, and it’s OK as long as we understand the tradeoffs, which will be security, usability, cost, and management overhead.

Options Analysis

Once you have the data, you can outline the options. Some of these won’t be available to you due to various constraints, such as how they work, cost, and others. These are listed in terms of most secure to least secure, and we’ll deep-dive into each section later.

  1. Supplied Devices - Give them devices you manage
  2. Managed Devices - They supply the hardware; you manage the software
  3. Isolated Browsers - browser-based access for SaaS-only workers
  4. Cloud Jumpboxes - A cloud machine which is required to access corporate systems
  5. Managed VMs - A managed VM on an untrusted host which is required to access corporate systems
  6. Posture-Based Exclusions - Only give access to your confidential data stores, not restricted data.
  7. Exception Rules - Put in exclusions for them to bypass your zero trust controls

Supplied Devices

In this example you do all the heavy lifting. You purchase devices, ship them to individuals, and manage everything on the devices. You treat them exactly as you would any other employee.

This option shines when you have money to spare and care deeply about hardware security. Hardware attacks are not something most companies need to worry about, and only the largest companies, often with data centers, need to worry here, so it’s usually reserved for the Amazons, Googles, and Apples of the world. This way, you can verify a device straight from the supply chain, all the way through its lifecycle to its removal.

You manage everything on the device and can implement any level of control you want, down to extremely heavy DLP alerting and highly restricted preventative controls like application allowlisting.

Managed Hardware

This option is very similar to the above, except the only difference is that the BPO or contractor provides the device. They buy a fresh device from their local supplier, which they then enroll in your MDM. You then proceed to manage everything on it fully from the software perspective.

This removes complexities such as logistics and hardware support but still gives you extremely powerful control of the device.

This breaks the trust chain in the very first step, but as mentioned, hardware attacks are among the rarest and not worth considering for 99.99999% of companies. Incidentally, this is the option I recommend to most people, but it is worth noting this is likely the most expensive option.

Isolated Browsers

Examples:

Isolated browsers are just browser instances hosted on dedicated infrastructure that an end user can access. This generally works by having the vendor or service provide a locked-down edge resource that only allows access to a browser but none of the underlying infrastructure, similar to a Platform as a Service (PaaS) design. In addition, they often come integrated with web browser management, which allows you to do things like limit extensions, stop screenshots, and run DLP detections.

These are about as secure as the cloud jump boxes below, if not more so, given that the user cannot install malware on the host. At worst, they could install a malicious extension if it wasn’t configured correctly. Additionally, one of the nice things about this approach is that it’s all HTTPS and done in the browser, so no special software is needed on the host device.

The downside of this approach is that it limits your user base to web browsing activities, which is often too restrictive for most. This may be OK for tier 1 support activities that primarily access a ticketing system and some basic web consoles. Still, it’s simply not going to work for anyone who needs to debug complex issues, spin up VMs, test local applications, and more.

I do recommend this approach if you can. It’s often cheaper and simpler to manage compared to cloud-hosted machines. With the caveat that you’ll really need to survey your user base first to ensure they can continue to work effectively in the confines of a browser.

Cloud Jump Boxes

Examples:

This option is cloud hosted machines, providing a visual interface to access and is commonly known as desktop-as-a-service (DaaS). This option is fine, but you are now breaking the chain of trust at a more critical point. There are fewer threats you are preventing with this model because a potentially untrusted device is connecting to your jump box. This means you’ll often have little to no visibility on the connected device, which could be compromised, contain malware or have someone nefarious looking to do insider threat things.

The benefit this gives you is visibility; you can log all the connections through the jump box, which means that it’s harder for threat actors to act, assuming that you have a good threat detection program. Similarly, with DLP, it gives you considerably more oversight than an unmanaged client device accessing your services directly if you roll this out. Some of the negatives here can be around pricing, as you’re paying for an entirely separate machine (which often does not have spot pricing available) and issues with internet connections, especially distance from data center locations and lousy performance on sub-par internet connections.

Pair this option with strong MFA and, ideally, some certificate-based access to the jump box, and you have a fairly strong setup that will prevent most commodity malware issues, such as ransomware and credential stealers. However, it **will not **protect against dedicated threat actors.

One critical decision you need to make is how you want to manage it. Microsoft365 is one of the few options you can manage like you would any other workstation, using an MDM. Similarly, you can use things like Jamf to manage Macs in AWS. Most other options out there are server solutions, including AWS Workspaces, which require a slightly different management approach, more akin to infrastructure management than end-user computing.

Managed Virtual Machines

Examples:

This is essentially a preconfigured VM that you spin up from your device. You then use this VM to access corporate services like the previous option, except it’s hosted directly from your machine.

This has many of the same pros and cons as cloud desktops, with a few extra caveats. On the positive, it is considerably cheaper since, with cloud desktops, you have an entirely separate machine you are connecting to. With this you are just using your already available hardware for compute. On the negative, there is even less security in this model as most VM security is usually designed to prevent container escape which is guest-to-host. In this case, a compromised host theoretically has full access to edit, change, and access containers as they please.

This is slightly lower in terms of security compared to cloud jump boxes. Again, if it’s set up correctly, it should protect against most commodity malware on the host, but there are more moving parts that can go wrong here. This may be a preferred approach for people with powerful hardware lying around and who want a price-conscious way to prevent commodity malware.

Posture Based Exclusions

With most zero trust setups, you have a series of application “tiers” in which your applications fall. This looks different for every company, but the most common setup is having three tiers:

Open Tier - These applications are accessible from any device.

Confidential Tier - These applications are accessible from less secure devices, commonly BYO devices. This often includes things like email, Slack, and communication apps, which are sensitive if exposed but often do not store significant quantities of confidential data such as PII or UGC.

Restricted Tier - These applications are the most sensitive and often include things like production applications, cloud infrastructure, and internal IT tools.

In this example you simply allow contractors to access only the confidential tier, putting some minimal restrictions in place. This could be traditional restrictions like IP allowlisting if the BPOs are all co-located, deploying certificates to their devices, or getting them to install a client application like Cloudflare Warp.

This keeps your most sensitive data protected, but again, this is only possible if your BPOs do not access sensitive data, which, in my experience, is rare. These people often provide support for your customers, and customer data is often restricted.

Exception Rules

This example is simple in that it just has you build in exception rules for BPO workers so they don’t need to meet your device compliance criteria. This is usually in the form of user-based exclusions in your identity provider.

Exception rules aren’t good for security, but they do occasionally have their place, usually as a stepping stone to something better.

You’ll find that some places audit specific suppliers. If they meet or exceed the criteria of their internal security policies, they are willing to put in long-lived exclusions for these users to save cost and management overhead.

Conclusion

There is no right or wrong answer regarding what you decide to use here, as long as you start by analyzing the usage patterns internally in your company and ensuring the solution works for your user base.

Yes, some are more secure than others, and I recommend you choose the most secure option you can. However, the most secure options also have the highest cost and management overhead, so don’t stretch yourself too thin by striving for perfection if you only have a small team. As always, be realistic about the threats that affect you the most when making these tradeoffs.

See the image below for my guidance on securing anything regarding end-user computing.

do not use computers