Don’t Blame the Intern for Your Bad Security

And other tips for avoiding infrastructure security policy misconfigurations

The SolarWinds hack is the story that keeps on giving.

Three months following the December announcement that the company had their Orion update server compromised, new details continue to trickle out.

Some of these have been fascinating like how the adversaries apparently used a very complex Golden SAML attack that undermined the otherwise strong protections on the server that left a lot of folks not-so-quietly applauding a pretty solid bit of hacking tradecraft.

Other tidbits like the more recent news that the company was using the less than bulletproof “solarwinds123” password for their update server are more embarrassing. The company then proceeded to make a bad situation even worse by blaming an intern for the oversight, claiming that the intern “violated their password policies” in their statement during congressional testimony.

To be clear, this mistake, even if it was done by an intern, was phenomenally bad. Please do not use passwords that even remotely resemble this one. Use a password manager to make long, unpronounceable, and unguessable passwords.

But despite the embarrassment and punchline-like attitude that many have taken to this gross oversight, we should be reminded of a valuable and painful point.

Errare humanum est — To err is human.

People in organizations make all kinds of mistakes all the time. Like really, really bad ones that can lead to a breach if a hacker comes across it.

In most cases, the cause behind these potentially critical mistakes is that people are not security minded by nature. The vast majority of folks who don’t work in security are simply not going to have security at front of mind.

Developers want to develop, DevOps wants to deploy, and so on.

Getting the job done comes first and security is often in the back seat. This is far from ideal but it is our reality.

Let’s look at a couple of common examples where basic mistakes can lead to plenty of grief.

Common Infrastructure Misconfiguration Mistakes

From our experience, we can break down most security issues on the infrastructure side of the operation on people creating bad policies and not reigning in access controls.

1. 1. Lack of Specificity

One of the most common security policy mistakes comes from not being specific enough in which resources should be allowed access or say write privileges to.

All of us at some point have probably thrown in that * to include everything, leaving way more exposed than should be in our policy.

1. 2. Using Admin Policy

Having to dole out access rights to each specific resource on a granular level can be a time suck and add more than a little friction into the relationship between your team and the good folks over at IT who get inundated with requests.

Why not just give everyone on the team admin privileges and call it a day?

Unfortunately this isn’t the most feasible of options. Granting admin privileges too widely expands the threat surface and makes it harder to manage your risk. The Principle of Least Privilege lays this out pretty well, stating that we only want to give people or machines the privileges that they need in order to do their job. Once we move past that line, we are taking unnecessary risk.

1. 3. Using AWS Managed Policy

For many organizations that might lack the knowledge about how to set up their Identity Access Management (IAM) policies, AWS provides a managed policy that can help them get started. These managed policies are based on common use cases and are maintained and updated by AWS.

Organizations should view these managed policies as a stop gap measure. They are better than nothing at all, but in general are more permissive than you should want for your organization.

No two organizations are exactly alike and your policies should reflect the specificities of your team’s IAM policies and needs.

1. 4. 3rd Party Access Controls

We depend on a wide range of 3rd party services and tools to support our work. But in order for them to be effective, we have to grant them access to our resources.

In general, giving this access to approved 3rd party tools is pretty run of the mill practice. The challenge though is in ensuring that we limit this access only to the services that we are actually still using.

Far too often, we simply leave access open to 3rd parties after we have ceased using them instead of revoking access like we should.

Given how common these mistakes are, it is worth taking a look at a number of steps that we can take to reduce our chances of making them ourselves.

Good Security Starts Early

The earlier that we can catch risky security configurations, the better chance we have of preventing bigger issues down the line when making a fix becomes significantly more complicated.

This is the driving concept behind the “Shift Left” movement that advocates testing and fixing issues as early as possible in a product’s lifecycle. Given the scale of modern infrastructure, we use automation tools to seek out issues like misconfigurations in security policies.

Automation is a key component of a successful security policy enforcement strategy not only because of the speed and scale aspects. It also helps to fill in the knowledge gaps for members of your organization that may not know how to properly make secure configurations. Automated tooling can catch those mistakes and even help them correct them in real-time without the need to involve the added friction of the Security team’s reviews.

So how can we try to prevent some of these misconfigurations? Here are a few of our favorite tips and tricks.

1. Utilize Automated Scanning

Automated scans can seek out risky configurations during the design and CI/CD process stages, identifying misconfigurations like excessive permissions or that pesky * that can leave you exposed.

2. Put Guardrails in Place

Enforce policies with automated guardrails that ensure that misconfigured policies are not allowed to make it into later stages of the product development. Let alone being deployed.

In some cases, it can mean even failing a build if that’s what it takes to make sure that every configuration leaving the shop is up to your standards.

3. Automate Security Policy Creation

Like we’ve said before, writing effective security policies is not a skill that everyone from Dev to DevOps and beyond is likely to have.

That’s why it helps to use tools that can analyze your policy and make the necessary corrections either fully automatically or with a single click. Using a run-time analysis, these tools can understand how your product is supposed to operate, figure out what the Least Privilege policy should look like and then write that policy for you.

Basically, this takes the work out of writing security policies and lets your people get back to doing what they are there to do, namely writing and pushing out your products.

Create an Environment Where People Can Succeed at Security

It is unclear why the leadership at SolarWinds decided to throw the blame at an intern for making a dumb mistake.

Even if the intern did something totally terrible, they were operating in the environment that the leadership had created.

If we want our people to work more securely, we can take a couple of steps. These can include training them on best practices, which is always a good thing to be aware of.

But it is still on us to create an environment where it is downright difficult to make serious security misconfigurations that can put the company and its customers at risk. Ideally at the earlier stages where we can still work to prevent mistakes from becoming way more serious challenges later.

One step that organizations can take to start improving their ability to handle issues early is by knowing where they stand now. Solvo can help make this discovery and assessment process a little bit easier with SecurityGenie, a free health check report that will give your team some much needed visibility.

You can get your free SecurityGenie report by following this link and take your first step to a more secure policy environment.