Pairing your Cloud with Offline Roots of Trust

By Drew Rothstein, President

Overview

Google posted about their Confidential Space product and how this can help manage digital assets more securely using a (highly available threshold) based on work originally led by Unit 410.

This is an expansion on their post with a focus on why offline cold storage remains the most important foundation in the digital asset security space.

Rings of Access

Just as an Operating System has a Protection Ring, access can be thought of similarly, and it can be useful to define your own protection rings as a means to communicate and inspect your configuration(s) and how you expect your system(s) to operate.

A couple examples to consider:

With your rings defined, it can help to communicate the same language internally and when you are starting to put together questions about how each ring is secured (or, should be secured).

What limits access to a GCP Confidential Space?

Google IAM Console

At an outermost ring of access, a Google Domain / Organization controls access to a Confidential Space, just like any Google Cloud Product. The configuration of a Google Domain / Organization that hosts your Google Cloud Platform can dictate much of your starting point for security.

Some initial questions to consider-

• Do any 3rd party services have access of any kind to your domain? How might this be abused?
• Who are your Domain Administrators with access to your Domain / Organization?
• How well-secured are your Domain Administrator accounts?
  • Do you use separate, hardware 2FA, unrecoverable, dedicated accounts?
  • Do you have alerting, logging, and auditing of when / how these accounts are used?

After you review and understand this outermost ring, going just one step deeper in the ring of access-

• What timeouts do you have configured for access to your Domain / Organization (configured in Workspaces)?
• What alerting do you have for suspicious activity / access?
• Do you have alerting on new location-based access or IP-based access?
• Do you have an alert on credential resetting?
• How do you manage the hardware that is permitted to access these accounts?

Google Workspaces Console

The co-mingling of Google Workspaces at these outermost layers adds to the complexity of access and permissions which is fairly opaque today for many organizations that have separate IT organizations from Engineering organizations. Even if they are the same organization, you likely have separate responsibilities and security perimeters / expectations for these roles.

The key is: It doesn’t matter how secure your innermost ring of access truly is – if someone outside your organization, maybe even just external to your engineering organization, can simply change a few permissions, impersonate a user, with little to no alerting, your super secret trusted execution environment may not be so super secret anymore.

Google IAM: The next set of rings

TF Enterprise Access Levels (ref)

As we have previously written about (1 | 2), Google Cloud IAM, which controls the next set of access layers, is complex and will usually require custom tooling to properly own and audit.

Following Infrastructure as Code best practices, you can choose to codify everything IAM. This can (and does) help secure your perimeter but is not a panacea.

Questions to consider-

• For the services you choose to run in a cloud environment, do you trust a managed provider (or CI/CD service) to execute changes to your IAM and how is that secured?
• Who has access to that environment? Who can make changes to that environment?
  • How frequently do you check (and apply) your entire IAM environment?
• How do you audit that your entire IAM environment is codified?
  • Do you perform internal and external audits?
  • Do you perform red-team exercises to attempt and exploit?

It is possible to have a nearly complete IAM codification but it takes an impressive amount of tooling and work to operate.

A single mis-codified Google Cloud IAM permission can let anyone control anything in your GCP account / project.

Service Accounts: Oh my!

Let’s say, for the sake of argument, that your user / human IAM management and access is perfect. How about all your instances that could be compromised and then have their privileges either utilized or in the worst-case privilege escalated?

More explicitly:

• If a single instance was compromised, and that instance’s service account was simply utilized (no additional compromise), what access could be gained?
  • Do you use dedicated service accounts for every instance? For every service? Or for every Google Project?
• If a single instance was compromised, and then privilege escalated to another service account (or key) in the Google Project, what access could be gained?

Even if you do everything up to this point perfectly, if you use a default compute account in your project (or even a shared dedicated service account / role with too much access) and a single instance is compromised, this could result in compromise of your trusted execution environment.

Do you really trust your Public Cloud IAM?

You probably shouldn’t. If you believe you have 100% perfect permissions, with no unexpected gaps, fully codified, and no mistakes – I’d love to offer a coffee and a chat! The reality is that you can write a lot of test cases, codify everything, perform internal and external audits, and you will still likely have gaps.

So, Offline?

Securing digital assets with multi-party computation is hard to do on a single public cloud environment / domain. Offline systems are not invulnerable but, by contrast, they trade an extremely large surface area that is publicly accessible (via APIs) to a much smaller surface area that is not publicly accessible or manipulatable without different physical access controls.

The ability to assert, with a much higher level of confidence, that the environment that you are operating in has not (and cannot) be accessed except by the services and people you expect, in the exact way you expect, is something that you simply cannot do with complete confidence in the Public Cloud today- Google or otherwise.

An offline environment allows you to put physical controls in-place that are auditable and are much harder to manipulate than Public Cloud environments where indirect changes can manipulate your account / environment with little to no visibility.

Conclusion

Enabling an offline environment to securely store and operate on digital assets can be done without exposing it to the Public Cloud. At Unit 410, we empower institutions to capture opportunities that others can’t.

We are currently hiring for a variety of roles: unit410.com/jobs.