Security meets Frugality

The five common security impacts from cost saving measures

Sadly we don’t all work for Silicon Valley or San Francisco unicorns.

For many of us running small or fast growing businesses, our runways, bank balances and budgets run a lot tighter and leaner. We save for things, we consider our options and a lot of the time we say no to things for financial reasons.

This week, GitHub announced a new pricing structure. They moved away from their legacy model which charged by the number of repositories and started to charge by the number of users with accounts. This makes perfect sense for them given how the resourcing and demand works for their teams but for many smaller or fast growing companies this was a big change.

For a team that uses GitHub with 100 developers and associated team members, this changes the billing from less than $100 per month for the whole team to $880 USD per month.

Ouch.

A lot of teams around the world had a conversation about software budgets that day.

We use a lot of tools like this now…

This isn’t article isn’t about GitHub, this could be about any high usage cloud service in our lives. This is about what happens in small teams (and their approach to security) when the prices suddenly jump (and money might be too tight to mention).

Let’s look at the five common mistakes that fast growing, budget conscious teams make when they are trying to save money…

Security spectres of the fiscally challenged

Penny pinching pitfalls that impact security and could cost you a lot in the long run.

1. Sharing is not caring (The rise of shared accounts)

One of the principles we encourage in security is to give everyone their own account. This helps us to do two things.

Firstly it means we can trace all activity to an individual and their account rather than trying to figure out which human was using a shared account today.

Individual accounts and audit logs are very important for investigating incidents and help us identify and response to compromise faster and with less business impact.

Secondly, it means we can simplify staff exit processes. This way when a staff member leaves, we cancel a single account rather than change a shared password. Leaving a shared account with the same password after a staff member has left — does not end well.

(Not to mention of course that shared accounts almost never have 2 factor authentication and often have poor quality passwords :/)

2. The rise of the all powerful (Permissions go wild!)

So you have decided to share an account because money is tight and you want to only use 5 accounts total. The likelihood is that you will make all of these accounts powerful to get the range of jobs done. This is a bad thing.

Going back to our security basics, we aim for the principle of least privilege with accounts. In simple terms this means accounts only have the permissions needed to do the job.

Shared accounts with high permissions mean we can do more things (and more damage) if an account is compromised.

If you aren’t sure if this is a problem for you, go and delete a repository from GitHub ‘by mistake’ and see how happy that makes your team.

3. An army of accounts (Everyone can have a GitHub team!)

Basic maths tells us that we could save a few pennies by having many 5 person teams rather than 1 large team.

While you will probably still get the job done, what is this going to do for your operations approach?

Suddenly one set of repository logs that need monitoring and caring for becomes a dozen.

You may have saved some money but you definitely just made your security awareness and defence picture a lot more difficult.

4. You’re not welcome anymore (Goodbye non-developers)

In times of famine we reduce our consumption to the bare minimum. You may be tempted to remove accounts from non-core developers. This means your technical writers, architects, UX and designers…. everyone who isn’t an engineer.

Bad news though! Just because these roles aren’t masters of deadlocks and micro-services, it doesn’t mean you can cut them off.

Those eyes and voices in your workspaces are asking you questions, increasing visibility and stopping assumptions in your approaches. To cut them off is to damage collaboration and collaboration is the key to security scaling over large teams.

5. Local instances for local people (The return of closet ops)

Once upon a time, one of your team ran a local instance of Git or SVN for some project or other and you decide its time to bring it in house.

That cloud thing was risky and expensive anyway right?

Stop.

Put down that VM and step away from the install.

Though we might all complain about the odd outages of our cloud systems, the big ones such as GitHub, Atlassian and Slack do a few important security things for us that we take for granted.

• They back-up professionally and manage them safely
• They respond to capacity requirements and deal with all that scaling nonsense
• They deal with security flaws and patch your instance without you even thinking about it
• They monitor the environment and respond to threats

So before you decide that the future is closet ops and you want to run your own instance internally, ask yourself honestly : am I doing all of this?

So before you do anything hasty…

Is $9 per user per month really that expensive? Or is it cheap for the amount of time and effort you are saving?

How much would it cost your company if by saving your pennies, you exposed your information, systems and people to risk?