If you’re like me, you think of Google Groups as the Usenet client turned mailing list manager. If you’re a GCP user or maybe one of a handful of SAML users you probably know Google Groups as an access control mechanism. The bad news is we’re both right. This can blow up if permissions on […]
If you’re like me, you think of Google Groups as the Usenet client turned
mailing list manager. If you’re a GCP user or maybe one of a handful of SAML users you probably
know Google Groups as an access control mechanism. The bad news is we’re both
This can blow up if permissions on those groups aren’t set right. Your groups
were probably originally created by a sleep-deprived founder way before anyone
was worried about access control. It’s been lovingly handcrafted and never
audited ever since. Let’s say their configuration is, uh, “inconsistent”. If an
administrator adds people to the right groups as part of their on-boarding, it’s
not obvious when group membership is secretly self-service. Even if someone
can’t join a group, they might still be able to read it.
You don’t even need something using group membership as access control for this
to go south. The simplest way is a password reset email. (Having a list of all
of your vendors feels like a dorky compliance requirement, but it’s underrated.
Being able to audit which ones have multi-factor authentication is awesome.)
Some example scenarios:
Scenario 1 You get your first few customers and start seeing fraud. You create
a mailing list with the few folks who want to talk about that topic. Nobody
imagined that dinky mailing list would grow out to a full-fledged team, let alone
one with permissions to a third party analytics suite that has access to all
your raw data.
Scenario 2 Engineering team treats their mailing list as open access for the
entire company. Ops deals with ongoing incidents candidly and has had bad
experiences with nosy managers looking for scapegoats. That’s great until
someone in ops extends an access control check in some custom software
that gates on [email protected] to also include [email protected]
Scenario 3 [email protected] gets a new investor who insists on using their existing
email address. An administrator confuses the Google Groups setting for allowing out-of-domain
addresses with allowing out-of-domain registration. Everyone on the Internet can
read the cap table for your next funding round.
This is a mess. It bites teams that otherwise have their ducks in a row.
Cleaning it up gets way worse down the line. Get in front of it now and you
probably won’t have to worry about it until someone makes you audit it, which is
probably 2-3 years from now.
Google Groups has some default configurations for new groups these days:
This is good but doesn’t mean you’re out of the woods:
Auditing this is kind of a pain. The UI is slow and relevant controls are
spread across multiple pages. Even smallish companies end up with dozens of
groups. The only way we’ve found to make this not suck is by using the GSuite
Admin SDK and that’s a liberal definition of “not suck”.
You should have a few archetypes of groups. Put the name in the group itself,
because that way the expected audience and access control is obvious to users
and auditors alike. Here are some archetypes we’ve found:
PS: Groups can let some users post as the group. I haven’t ran a phishing exercise that way, but I’m guessing an email appearing to legitimately come from
[email protected] is going to be pretty effective.