Get a demo

OneKloud - Blog

How to Avoid Cloud-Credential Theft

[fa icon="calendar"] Dec 6, 2016 4:04:00 PM / by Sarah de Castro

Sarah de Castro

Quit paying for AWS that’ve been hijacked using stolen cloud credentials.

Hacks like data breaches and stolen keys are the result of: bad access administration, credentials that aren’t carefully chosen and mismanagement of key certification.  Companies are now realizing this lack of control is too costly to ignore.

Giving it up easy

Companies so often don’t take identity management seriously enough. Unrestricted permissions are routinely given to anyone who asks, including new recruits and freelancers.

And worse still is unrestricted permissions for everyone in the hierarchy, so you have a situation where the CTO has almost the same access as the intern there for two weeks… permissions, passwords and access that aren’t revoked when the person leaves.

Is this kind of risky exposure the price to pay for agility and flexibility?

No Holds Barred

The to-be-expected pitfalls of corporate life?  Administrative details that haven’t been adapted into the workflow as businesses scale up. Everyone’s doing it in the way they learnt, without adhering to an official policy, or understanding the importance and potential impact of corporate security breaches

There are ways around this like setting up Identity Access Management (IAM) systems that make it harder for hackers or robot attacks. Yet because these systems are often considered too complex or time-consuming and not appropriate for companies with high, or actually any turnover. Few implement these measures.

Exposed in Code

Even professionals don’t play it safe. Many developers make the mistake of embedding credentials and cryptographic keys (the data that lets your applications interact with each other, like when they order AWS) in source code and leaving them in public-facing repositories such as GitHub. This doesn’t just leave data exposed to hackers on the lookout to make mischief,  but exposed to robots, which are especially designed to crawl code and sites for this kind of data, which can then be sold to be used illicitly.

For many programmers it's a Catch 22, because they see it as part of the request and therefore they include credentials  in the instructions. A little like trying to order a pizza without a credit card. Or take an Uber without an account.

A Massive Impact

So while this may seem like another office frustration, the problem is that this annoyance (unlike forgetting to restock the photocopier paper) costs an average of $10,000 per hack and this after a reaction time of around 2 full days.  

When a  key is exposed and used illicitly, there are 2 direct effects: firstly your company ends up paying for services you didn’t use and secondly your cloud provider - in order to protect their infrastructure - is going to revoke your keys without notification, this shuts down your services, and forces your company to urgently change all credentials for everyone, everywhere… time during which your services are down. The impact on business is massive.

Not Exclusive

But this issue is not limited to companies dependent on cloud infrastructure. Just think of the infamous Ashley Madison hack  or the Anthem breach, where hacked user credentials left 80 million customer records exposed, because they failed to deploy multi factor authentication. Both left the companies permanently stained and their trust severely compromised.

Everytime credentials are leaked, the company pays big, both in dollar value and in term of a compromised image.  Imagine the AWS key used to develop a multi-factor authentication code being stolen. Both the infrastructure and all the data stored inside the account is then comprised. It’s a big deal.

Nowhere to Hide

You simply can't secure a password or key inside source code. You might obfuscate it or otherwise try to conceal it and use other operations to "cover" it but in the end there has to be some way for it to be put together to make the function operate.

This is an issue that can’t just resolved by telling programmers no, and a slap on the wrist. It needs to prevented.

Mistakes: Prevention

This is an issue for upper management, and an issue that needs to be enforced and prevented not just acknowledged helplessly when it’s too late. And this is possible - by using alert systems and actually preventing the possibility of this happening by limiting the resources that are on hand and can be deployed at one time (like using a debit card instead of a credit card to pay do online shopping).

Careful of Your Keys

Keys need to be rotated periodically to make it harder for attackers to use keys they’ve obtained without authorization.

Ideally, you need to add a key obfuscation mechanism and a key per project and per developer. Unfortunately, the tools offered by native cloud providers make this task almost impossible

Our Experience

Here at OneKloud, we noticed with our first customers that by implementing OneKloud (a solution designed with budget control in mind)- a big part of these security challenges were solved.

Native OneKloud features are focused on users and projects. An internal “etanche” proxy mechanism is established before ordering Cloud APIs, therefore unforecast cloud costs are blocked and management is alerted in real-time.

So while we pride ourselves on a unique workflow system, which lets companies stick 100% to their cloud infrastructure budget forecasts, an extremely beneficial impact on security is a very happy side effect.

 So what do you think? What's your experience or advice on stolen credentials & misused keys? Join the conversation by leaving a comment below...

Topics: Security, Cloud Credentials

Sarah de Castro

Written by Sarah de Castro

Cloud-enthusiast and storyteller, Sarah is a content strategist at OneKloud. Explorer of the technology landscape, she boils down technical and complex ideas for everyday digestion (and enjoyment). With an appreciation for sophisticated simplicity, linguistics and branding, she is a global local in Paris from New Zealand.