Alex - stock.adobe.com
With recent high-profile breach disclosures as its guide, financial tech firm Mercury continuously refined its zero-trust security practices in a bid to stay ahead of attackers.
As a remote-first company, Mercury emphasizes securing remote access, especially for its hundreds of software engineers. This priority as well as cautionary tales from two major breaches in 2022 influenced Mercury's choices as it swapped an open source VPN for easier setup with SaaS, rolled out device security software and reworked its incident response plan for security tokens.
When he joined the San Francisco-based firm in early 2022, Branden Wagner, Mercury's senior information security manager, brought with him experience working with tech in the Naval Sea Systems Command and Naval Nuclear Laboratory. But he encountered a much different security culture in the private sector.
He soon began efforts to bring corporate zero-trust practices closer to the military standard through a "thought exercise" with engineers and executives based on other companies' published security incident reviews.
"Taking my experience on the classified side and kind of trickling it into the private sector, I found the biggest [incentive] is just to do these case studies with every major breach," Wagner said. "Take out that company's name, put in Mercury's name, and [say], 'Tell me why it can't be us.'"
LastPass breach prompts device security via fresh VPN
In late 2022, shortly after password management vendor LastPass first disclosed a major data breach, Mercury was searching for a new VPN tool. At the time, it was using open source Pritunl, which supported enforcing the use of physical security keys to gain access to corporate networks. Pritunl also worked well with the company's Okta identity management system.
"We require a physical token for access to the inside network, and a lot of VPNs don't do that or don't do that very well. It's kind of a niche security thing that a lot of people aren't doing yet," Wagner said.
However, the user experience with Pritunl left a lot to be desired, especially when onboarding engineers working from home.
"We would spend an hour a week with new hires just trying to do setup," Wagner said. "Less than 5% of our employees could set that predecessor up without tech support, and we hire a lot of really smart engineers. If they can't figure it out, it's a problem."
As a SaaS offering, Tailscale's VPN software helped solve that setup problem, and its distributed architecture also lent itself well to zero trust. Tailscale builds on the WireGuard open source VPN project, which creates lightweight encrypted tunnels between endpoints.
Tailscale's software converts WireGuard's hub and spoke tunnels into a mesh network, where a control plane handles key management and encryption for a data plane of distributed endpoints connected to one another without relying on static IP addresses or a centralized VPN concentrator. This makes the VPN more scalable than traditional centralized versions of the technology but also gives SecOps teams finer-grained control over access to each connection between endpoints.
"With Pritunl, all users had access to everything or nothing, and then we had to put other controls in place to kind of lock things down," Wagner said. "With Tailscale, [users] could get into development [environments] and have a little bit more freedom there, whereas when [they] got to production, it was way more locked down."
When an updated breach postmortem from LastPass in February revealed that a remote developer's home machine had been compromised to give attackers their initial foothold in the company's cloud back end, Wagner took note.
"Before that, we had been testing Okta Kolide [Device Trust]," Wagner said. "But that's when we rolled it out company wide."
Under the new system, every new device trying to access Mercury's network requires manual approval. Okta Kolide Device Trust first automatically ensures the device complies with the company's security requirements, and Tailscale validates that only approved devices get access the network.
After CircleCI breach, rethinking tokens
In January, DevOps SaaS vendor CircleCI disclosed a data breach that had hinged on the use of a compromised security token. In response, customers were advised to update any secrets stored in CircleCI's systems, including OAuth tokens, project and user API tokens, project environment and context variables, project SSH keys, and runner tokens. Some customers' AWS API tokens were also compromised. For many SecOps pros among CircleCI's userbase, this meant days of toil to secure their systems.
Mercury used CircleCI for some non-production testing workloads, which it scaled back after the breach. This time, Wagner's thought exercise focused not just on ensuring Mercury wasn't compromised as a CircleCI customer but also how it could avoid the fate of CircleCI itself.
"We looked at, 'Where do we have tokens?' We had a pretty good inventory already, but it made people go through and look at it again," Wagner said. "Then we talked about, 'Let's say that one of our tokens was breached. Do we have a procedure to roll that token? How do we replace it? What's downtime look like? Who's affected? What partners need to know about it?'"
This last question revealed an opportunity for improvement. In some cases, Mercury lacked a specific point of contact at partner companies in the event of such an incident. Thinking about CircleCI's breach prompted it to update that information.
Some of those partners had a surprising response to being contacted, Wagner said.
Branden Wagner Senior information security manager, Mercury
"Not everybody treats security the same way," he said. "We had some partners that were like, 'Why are you doing this? Why are you wasting our time?' Well, maybe we should reevaluate our security relationship, because this is kind of important."
Reevaluating security relationships, practices and tools is also easier at a relatively new company such as Mercury, which was founded in 2019, Wagner acknowledged.
"We were born in the cloud, so we don't have a whole lot of legacy equipment," he said.
Tailscale's SaaS has made setup and management easier, but Wagner said he'd prefer to have a self-managed version eventually.
"That was our biggest hesitation in moving forward with Tailscale," he said. Wagner also had this concern about Okta, which is delivered via SaaS as well.
To mitigate SaaS risks, Mercury's SecOps team has extra monitoring and logging in place where it does have visibility into Tailscale and Okta connections.
"We've also run through some different scenarios for an incident response should they get compromised," Wagner said.
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.