Forem: Common Fate

Who Cares About Least Privilege?

Common Fate — Thu, 03 Nov 2022 04:24:04 +0000

Security professionals agree that least privilege is a foundational part of secure design. So then why do so few organizations care about it?

According to most companies that sell security tools, the world is a dangerous place. Hackers are everywhere. They’re crawling around in your EC2 instances, in your employee laptops, in your Gmail inboxes. They’re hiding behind your watercoolers and under your meetings tables and in your breakout booths. Half of your employees are hackers. Hell, your CISO is probably a hacker too — you should fire her and buy more tools.

Billions of dollars are spent around this issue. State-of-the-art WAFs, AI-assisted endpoint protections, eye-wateringly priced security logging solutions that take entire teams just to set up and manage — and yet almost zero care seems to be directed towards one of the simplest and most cost-effective defenses: least privilege.

I’d like to state upfront that this won’t be a persuasive article. I have no grand idea to sell you, no concrete answer to this problem that we’re facing. I’m the Developer Advocate for a company that makes least privilege workflow software, which means the bulk of my job is arguing in comment sections about why least privilege even matters. This article, if anything, is a cry for help.

All I can really do is share the things that we’ve discovered while working in this space, and hope that you’ll share your own insights too. And maybe then we can start thinking about how to solve this thing.

So then why do so few organizations bother to properly scope employee privilege?

Problem 1: They think it’s about trust

Imagine, for the sake of argument, that there is a lava pit in the middle of your office. Most of your co-workers are so used to the lava pit that they don’t even notice it’s there, while a few others have actually created entire geothermic systems that require the lava pit to function. Occasionally someone will fall into the lava pit, suffer grievous injuries, and then be sent into lava pit awareness training.

One day you meet with one of the infrastructure teams to discuss how maybe instead of having lava pit awareness training, we should just get rid of the lava pit. The outrage is immediate: w*e’ve always had the lava pit! Too many systems rely on it! Getting rid of the lava pit would mean redesigning the entire floor!*

Out of all these objections, one of them seems to stand out the most: but we trust our people to not fall into it.

Of course, it’s a ridiculous argument. No one chooses to fall into the lava pit, just as no one chooses to get phished. But it’s one of the more difficult points to argue against. As an engineer, it’s hard to not feel patronized when your lava pit is taken away. Sure, maybe other people in the company are incompetent goons — but you’d never fall into the pit. You’re too smart for that.

Accepting least privilege means admitting to yourself that no matter how smart and good at computers you might be, sometimes shit happens — and you are not immune to it. This is a difficult realization for anyone.

Problem 2: Move fast, break things

No one ever got seed funding for not getting hacked.

Many growth-focused companies tend to sacrifice security in favor of pushing out their product quicker. The narrative is usually “we’ll make it secure once we’ve actually built it”. The issue is that security debt works just the same way that tech debt does — all these oversights and shortcuts accumulate to eventually make any sort of positive change almost impossible. Giving people sweeping amounts of access results in them creating workflows that rely on that over-privileged access, and as more time passes those processes become more ingrained. Removing people’s access is a hell of a lot harder than just not having given them that access in the first place.

This is a problem that mostly applies to startups and rapidly scaling companies (large business have no problem putting red tape around every single access request and process — most of their executives probably have KPIs based around doing so).

Problem 3: What’s your job again?

Implementing least privilege requires actually knowing what all your coworkers do.

That’s an easy enough thing if you work in an organization where everyone has clearly defined roles and never has to step outside those roles to help someone else or meet a changing requirement. But you don’t work in that organization, because it doesn’t exist and we live in Hell.

Any good least privilege architecture must assume that people will sometimes need to do things outside their roles. Overly broad permissions are dangerous, while extremely scoped permissions can limit cross-team functionality and kill creativity. It’s not an easy balance to strike, and ultimately this requires a lot of communication between the security team and everyone else — which, let’s face it, is a whole other article.

Problem 4: It’s all business, baby

This is a section that I hesitate to add, and if it’s included in the final article then it’s only due to the good grace and patience of the people who pay me. But there’s a problem in the business of security: and it’s the business part.

In an earlier company I worked at, I once met with the CFO to request budget approval for a new security hire. I will never forgot what he told me: “What’s the ROI on security?”

I could have replied “what’s the ROI on looking both ways when you cross the street?”, but I didn’t. That was a line that came to me months later, when I was still the only security hire and still bitter about the meeting.

At the time, I thought the CFO was naive and had no business sense. But he was right: there is no ROI on security, only on security optics.

Good security can save you lots of money years down the line, but businesses don’t work on a timescale of years. They work in quarters. Investors want to see what you’ve achieved in the past three months, and telling them that you’ve become unhackable by buying a machine-learning anti-virus is a hell of a lot more impressive than telling them you’ve taken away Dylan’s root access to all the customer data. The first one lets you show off slides full of cool graphs and mean-looking falcon logos, and the second one gets people asking: why the **** did Dylan have root access to all the customer data?

The problem, of course, is that buying the cool anti-virus is often a lot cheaper and less problematic than taking away Dylan’s access. So, here we are.

Problem 5: Implementation

In security, the most interesting (and difficult) problems tend to involve people, not technology. Unfortunately, most least privilege solutions are blatantly anti-people.

No one wants to fill out a Google document and then figure out who to email it to just to get access to a basic part of their job. No one wants to look at tickets on a kanban board just to figure out who they need to give access to. And no one wants to go through all the IAM roles to discover that the penetration tester from two years ago still has AWS access just because no one remembered to revoke it.

So that’s why we’ve created Common Fate, an open-source developer workflow tool that helps you request and approve specific, timeboxed permissions with just a few clicks.

What? Did you think we were going to write this whole thing without advertising our product even once? Nah.

So what do we do about all this?

Honestly? I don’t know. On a more granular level, each of the above problems have their own solution. Talk to your coworkers about how you trust them, you just don’t want to take unnecessary risks. Make sure to do good security design before you need to pay KPMG $25 million to fix it for you. Talk to your coworkers about what their jobs actually are. Check out our Github repo, etc. etc.

On a more holistic level, many of these problems are underpinned by a common factor: an organization’s inability or unwillingness to properly map out their structure and commit to designing better permission workflows. The inability part can be solved with a bit of time and strategy — the unwillingness part, not so much.

How to log in to multiple AWS accounts — the easy way

Common Fate — Thu, 15 Sep 2022 03:49:52 +0000

Here’s how it goes: you’ve got a Chrome window open for your Production AWS account, and a Firefox window open for the Staging account. There’s a Safari window open for the Dev account, and an incognito Firefox window open for the Sandbox account. Buried somewhere in your dock’s 200 open windows is a Chrome incognito account for the other Sandbox account (because your org really, really cares about account-level separation), but by the time you manage to find it your session will probably be expired and you’ll have to go through the whole kerfuffle of signing in again.

I can’t explain to you why AWS decided to make their user experience like this — who am I to question the will of God? But I can offer you a solution: a simple, open-source CLI tool that’ll take you 10 minutes to install and will save you from AWS browser window hell forever.

Here’s how Granted CLI works. Run the assume command in your terminal and pick which AWS profile to sign in to (in my case, testing):

And in a few seconds, it’ll open a new tab in your browser of choice (in my case, Firefox):

Now let’s say you want to work in a second AWS account simultaneously. All you have to do is run the same command, this time selecting a different profile (in my case, release)

And then you’ll have a second tab open in a new container:

You can switch between these tabs to work in these accounts simultaneously with no extra hassle. Opening another profile is as simple as just running another command.

If you think this is as cool as we do, you can read our Getting Started guide to get set up with Granted — but to save you a click I’ll run through the MacOS instructions here (the Getting Started guide contains specific instructions for Linux and Windows, too).

First, you’ll need to set up at least once role in your AWS config file. On MacOS, this is stored in ~/.aws/config. A config file for AWS SSO should look something like this:

# ~/.aws/config
# Change the values below to match your AWS SSO configuration
# Granted uses the profile name: in this case 'my-profile' to choose the role.

[profile my-profile]
sso_start_url=https://mycompany.awsapps.com/start
sso_region=us-east-1
sso_account_id=123456789012
sso_role_name=DeveloperRole
region=us-east-1

(you can use AWS IAM too - but we recommend SSO.)

Once you’ve got that set up, you can use Homebrew to install Granted:

brew tap common-fate/granted
brew install granted

And verify your installation:

➜ granted -v

Granted v0.2.9

(mine is v0.2.9 at the time of writing — yours will probably be a later version)

Once you’ve verified that Granted is installed correctly, you can run the assume command to get started with the setup wizard where you’ll be prompted to choose your browser.

After setup, you can run assume again to choose roles:

You can also pass the role name directly and use the -c flag to open the console, e.g. assume -c testing.

And that’s it! If you’ve got any questions, you can check out the docs or join our Slack where we’ll be happy to chat with you directly. And if you like Granted, you can follow our Twitter for updates and terrible jokes.

Happy ClickOpsing!

Prevent Logging Secrets in Go by Using Custom Types

Common Fate — Wed, 17 Aug 2022 02:31:00 +0000

In our codebase for Granted Approvals, we’ve got a structure that looks like this:

type Provider struct {
    OrgUrl string
    APIToken string
}

In this case, we’ve got a value named apiToken. It’s a secret, and we’d rather it doesn’t get leaked somewhere. Your secret value could also be an API token, or maybe it’s a password or a user address or anything else that you don’t want to get a Privacy Act lawsuit for.

The trouble with storing your secrets in strings like this is that it’s very easy to accidentally log them. It only takes one fmt or zap line for your secret value to be printed in plaintext and then possibly even sent to your external logging solutions. Using unexported fields can help, but Zap will still include them anyway.

If you’re reading this, then you probably already know why having sensitive data in your logs is dangerous. If you don’t, you can check out this. Or this. Or this. Or…. you get the point.

And if you’re rolling your eyes and saying I’d never log sensitive data, I’d ask: are you sure? You’re never going to accidentally type the wrong variable name in your print function? You’re never going to have a new dev join your team? Nobody on your team is ever going to be one night away from a deadline debugging why the hell the password reset function isn’t working and just go screw it, I don’t get paid enough to care about security anyway? I’m not so sure.

Our solution: custom types.

type Provider struct {
    OrgUrl StringValue
    APIToken SecretStringValue
}

Now instead of orgUrl and apiToken being type string, they’re StringValue and SecretStringValue. Both of these custom types provide a small abstraction over a standard string type:


type StringValue struct {
    Value string
}

type SecretStringValue struct {
    Value string
}

The part that’s important to us though is how they both implement the Stringer and MarshalJSON interfaces:

func (s StringValue) String() string {
    return s.Value
}

func (s StringValue) MarshalJSON() ([]byte, error) {
    return json.Marshal(s.String())
}

func (s SecretStringValue) String() string {
    return "*****"
}

func (s SecretStringValue) MarshalJSON() ([]byte, error) {
    return json.Marshal(s.String())
}

The String() implementation for SecretStringValue will only return the redacted string “*****”, and same goes for the JSON. This makes it a whole lot more difficult to accidentally log the secret by just plugging it into fmt or zap.

So now, if you’re got something like:

oops := Provider{OrgURL:"commonfate.io",APIToken:"secret"}
fmt.Printf("%s", oops.APIToken)

or:

oops := Provider{OrgURL: "commonfate.io", APIToken: "secret"}
b, _ := json.Marshal(oops)
fmt.Print(string(b))

All you should hopefully get in return is ***** or {"OrgUrl":"commonfate.io","APIToken":"*****"}.

Is it totally foolproof? No. You can still log the secret if someone decides to deliberately print the Value, but at least now the team has clearer context on whether or not something is intended to be a Secret or just a regular Value. It makes it just that little bit harder to make a mistake — and in security, that’s all we can really ask.

If you want to check out the code for yourself, here’s a Go Playground link. And if you’re interested in seeing how we’ve implemented this in our own project, you can check out our gconfig package.