The separation of work and play

Mixing work and personal contexts can provide a better employee experience and increased security risk. Here we look at specific scenarios, risks, and available controls to help startups find balance.

An ever present topic in the risk assessment of a startup is some version of staff using work machines for personal things, and vis-a-versa. I want to cover some of the common manifestations of this pattern, and my approach for evaluating the risk.

Risk scenarios

Personal email on work machines

Email was the second most prevalent vector for breaches in the 2023 Verizon DBIR¹. It is also ~necessary for everyone to have it on their work machines.

Having personal email on a work machine increases the risk of an email-based attack succeeding against a startup. It’s not obvious why this is the case, but there are some specific risks that apply.

Corporate email systems can implement detection and prevention controls for malicious emails. These same controls can’t be implemented on personal accounts. This means you have to rely on built-in spam filters, which are far from perfect for this use case.

Personal inboxes also receive different types of emails than corporate inboxes on a normal basis. This expands the range of plausible pretexts which can lead to a malicious email being acted upon from a corporate device.

Sometimes attackers will compromise one person’s email account and respond to old conversations in their inbox with attempts to compromise the counterparties. The pretext of the existing thread makes the attempts more convincing. This is called business email compromise (BEC).

Checking personal email from a work device increases the number of existing conversations and counterparties who could be compromised and used as a vector for attacking corporate accounts through BEC.

Work email on personal machines

When someone logs into corporate email accounts from a personal device, they expose the contents of that account to software running on their personal computer.

Malware and malicious browser extensions can compromise sensitive work emails, and this access can even be leveraged to gain access to other systems (e.g. anything using Login with Google).

Enterprise security controls like antimalware, endpoint detection and response, secure DNS, application allowlisting, and more aren’t running on personal computers and will not have any ability to detect or prevent an attack.

People typically have their personal email on their personal computers as well. This presents a direct line of attack to corporate systems which completely bypasses all detective and preventive controls.

Personal GitHub in work organizations

When a new employee joins an organization that uses GitHub, it is common for them to have their personal GitHub account added to the organization’s account. It is less common for them to create a new GitHub account dedicated to that particular company. GitHub recommends that people have one account used for both personal and work contexts².

Bad passwords and SMS MFA

Any account that requires a password is liable to have an insecure password. Password reuse is common, and old passwords are often leaked in major data breaches³.

Some accounts may not have MFA enabled, and those that do may use less secure methods such as SMS codes.

Insecure passwords and MFA configurations are risks that apply equally to personal GitHub accounts and accounts created specifically for an organization. There doesn’t seem to be anything special about personal accounts that make these risks more pressing.

Old SSH keys

You can also authenticate to GitHub with SSH keys. Each user has the ability to create as many SSH keys as they’d like. It’s common practice to create one per device.

The upshot here is that personal GitHub accounts have many SSH keys, including on old servers and devices that are long forgotten. It can even include servers and devices from previous employers. When this account is granted access to your organization, those keys all have access now too, with no second factor.

Requiring employees to create separate accounts for work ensures that you're starting from a clean slate and you won't have this long tail of SSH keys being granted access to your organization.

Personal access tokens

The third authentication scheme for GitHub is personal access tokens. There are two types: classic and fine-grained. Neither of these requires a second factor to authenticate, regardless of the normal account settings.

Classic personal access tokens grant the holder access to everything the associated user can access. When the user is added to a new organization, existing tokens now have the same permissions. These tokens are often used in scripts running in any number of places (e.g. CI/CD). Requiring new work-only accounts doesn’t carry the risk of old tokens being used to access your organization’s assets.

Fine-grained personal access tokens have the benefit of additional scope limitations and security requirements. They are limited to specific users or organizations, so adding a personal account to your organization won’t result in old fine-grained tokens having access to your organization. Any tokens will have to be created specifically for your organization, and the associated risk applies to both personal accounts and new work accounts.

Dotfiles and Codespaces

If your organization uses GitHub Codespaces, users can choose to automatically install their own dotfiles in Codespaces⁴. GitHub lets them choose an arbitrary repository where it will look for dotfiles to install whenever a new Codespace is created.

Dotfiles have the ability to run arbitrary scripts. Some users choose a personal repository where they keep their preferred dotfile configurations. An attacker who can modify the personal repository will have the ability to run arbitrary code in your Codespaces. Codespaces often have access to private code, and sometimes live systems. This can be used to advance the attack into the organization.

GitHub only allows selection of a repository owned by the user⁵. This means that requiring a new work account for your organization reduces the risk of a personal repository with different contributors, access patterns, etc. being used to access your resources.

Some of the controls we will discuss later in this essay apply to organization resources, but not personal repositories. Using dotfiles in this way bridges the gap and allows an attacker to pivot from the latter to the former.

GitHub summary

These risks are more potent when you add existing GitHub accounts versus asking new team members to create new accounts:

• Old SSH keys

• Personal access tokens (classic)

• Malicious dotfiles run in Codespaces

These risks are about the same either way:

• Bad passwords and MFA

• Personal access tokens (fine-grained)

We’ll discuss the controls available through GitHub Enterprise in a bit, which can change the conclusion a bit if that’s an option for you.

Potential controls

SWG and CASB

Secure web gateways (SWG) and cloud access security brokers (CASB) can be used to enforce granular controls on which accounts staff can access from their work machines. They essentially work by proxying all web traffic and blocking attempts to access email or file-sharing accounts that are not explicitly approved.

These tools can prevent access to personal email from work machines, reducing the risk of social engineering or malware attacks which would otherwise be caught by work email filters. They can also block attempts to access malicious websites or certain content categories like illegal streaming or file-sharing sites.

The downside of an SWG is that it will be perceived as heavy-handed and intrusive by some of your colleagues. Some of these tools proxy traffic through a remote server, resulting in increased latency for web traffic.

Conditional access

Conditional access is a way of only allowing access to corporate resources if certain conditions regarding the attempt are true. You can restrict IP addresses, enforce that only corporate devices are used, and even that antivirus software is running or the browser and operating system are up to date.

Conditional access can be used to prevent access to company email accounts from personal devices. This requires a slightly more advanced IDP / SSO / MDM setup than many startups have, but is a great security control.

There are many benefits to conditional access with more or less friction added for end users, but for the purposes of this essay if you have the tools to set it up, it’s low friction for users to require that you come from a corporate device.

You can choose to make exceptions for mobile phones, since they aren’t typically vulnerable to the same kinds of malware as desktop / laptop workstations. With mobile phones the primary risk is that terminated employees may retain access to corporate email.

GitHub

Many of the security controls available to safely implement GitHub’s recommendation of granting personal accounts access to your organization require GitHub Enterprise.

The Enterprise plan costs $21 / month / user versus $4 / month / user on the Team plan at the time of writing⁶. It includes both the ability to require separate SSO login on a personal account when accessing work repositories, and the ability to enable Enterprise Managed Users, which are fully owned corporate accounts provisioned from the identity provider.

---

It would be a better fit to have the extra login setting available on the Team plan, and reserve Enterprise Managed Users for the Enterprise plan.

See my essay on this general subject:

A balanced approach to premium security features

---

Summary of available GitHub controls

• Require SSO to access corporate resources from personal accounts

  • Availability: GitHub Enterprise

  • Gaps: Personal repositories can be used for dotfiles on Codespaces, SSH keys, classic personal access tokens.

• Enterprise Managed Users

  • Availability: GitHub Enterprise

  • Gaps: Stolen cookies from malware, stolen personal access tokens.

• IP Allowlisting

  • Availability: GitHub Enterprise

  • Gaps: Malware accessing GitHub from compromised endpoints (“living off the land”)

• Require MFA to be added to the organization

  • Availability: All organizations

  • Gaps: Insecure SMS MFA, SSH keys, classic personal access tokens

• Restrict access from classic personal access tokens

  • Availability: All organizations

  • Gaps: SSH keys created by classic personal access tokens will still work⁷. Many organizations use classic personal access tokens out of necessity and can not disable them across the board.

The most secure configuration for an organization with GitHub Enterprise would be to use Enterprise Managed Users and an IP allowlist. This would require any attacker to steal session cookies or personal access tokens and execute the attack from an endpoint within the IP allowlist.

The most secure configuration for an organization without GitHub Enterprise would be:

• Require MFA

• Restrict access from classic personal access tokens if possible

• Ask new team members to create a new account for their work context; or

• Ask new team members to review their account’s SSH keys and classic personal access tokens before being added to the organization and not to use personal dotfiles repositories for Codespaces.

1. https://www.verizon.com/business/resources/reports/dbir/

2. https://web.archive.org/web/20240130175704/https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-your-personal-account/merging-multiple-personal-accounts

3. https://haveibeenpwned.com/

4. https://web.archive.org/web/20240129143139/https://docs.github.com/en/codespaces/setting-your-user-preferences/personalizing-github-codespaces-for-your-account#dotfiles

5. I didn’t find this asserted in the documentation, but it appears to be the case when I tested it out in practice.

6. https://web.archive.org/web/20240201110626/https://github.com/pricing

7. https://web.archive.org/web/20240120165937/https://docs.github.com/en/organizations/managing-programmatic-access-to-your-organization/setting-a-personal-access-token-policy-for-your-organization#restricting-access-by-personal-access-tokens-classic